Currently, there are situations where Remote WebGL is disabled due to
lack of HW support (For example, if it is run in a Virtual Machine)
This makes it so that the WebGL remoting is enabled anyway, since it is
needed for Win32k Lockdown.
Differential Revision: https://phabricator.services.mozilla.com/D135649
This patch adds a checkbox at the end of each event listeners in the EventTooltip,
which allow the user to disable/re-enable a given event listener.
This is done by managing a Map of nsIEventListenerInfo object in the NodeActor,
which we populate from `getEventListenerInfo`. Each `nsIEventListenerInfo` is
assigned a generated id, which can then be used to call the new NodeActor
methods, `(enable|disable)EventListener`.
We don't support disabling jquery/React event listeners at the moment, so we
display the checkbox for them as well, but disabled.
Differential Revision: https://phabricator.services.mozilla.com/D135133
In Bug 1724480, a change was made to not sync libraries if there is no compile
environment.
This change did not account for artifact builds, for which there is no compile
environment but do have libraries anyway.
Differential Revision: https://phabricator.services.mozilla.com/D135721
geckoview-exoplayer2 does not differ between lite and omni builds so we don't
publish an -omni version.
The dependency to exoplayer2, however, does specify the -omni suffix so
geckoview ends up depending on a non-existent geckoview-exoplayer2-omni.
To fix this we don't add the -omni suffix in geckoview-exoplayer2 and keep it
only for geckoview.
Differential Revision: https://phabricator.services.mozilla.com/D135707
We decided to keep it when initially making scrollbars non-native, but I think
it's time for it to go, since it's pretty much untested.
Nobody has complained about the non-native scrollbars in chrome documents, and
the GTK scrollbar implementation is not suitable for content because it doesn't
support scrollbar-width among other things.
Differential Revision: https://phabricator.services.mozilla.com/D135670
Since bug 1747116 landed, if the compositor is reinitialized whilst
the Android Surface is invalid, we avoid crashing when querying the
window size and instead keep the compositor in a paused state.
However, in this case we will believe the widget size is 0x0 until the
compositor is eventually resumed. If webrender receives a display list
during this time, it will set an empty view rect. This means when the
compositor is subsequently resumed webrender believes it has nothing
to render, and we get stuck in a state where nothing is ever rendered
to the screen.
This patch initializes the AndroidCompositorWidget with an initial
size, which avoids the problem.
Differential Revision: https://phabricator.services.mozilla.com/D135711
We have this situation right now where all the themes are inheriting from
nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at
it.
In the future I'd like to simplify the inheritance chain to remove
nsNativeTheme altogether (so that all nsITheme implementations use
mozilla::widget::Theme).
That's not hard to do mechanically, but rather than dumping all of
nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully
remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on
and use something nicer. Eventually the inheritance chain will be something
like:
* nsITheme : public nsISupports
* Theme : public nsITheme, public nsITimerCallback, public nsINamed
* ThemeCocoa : public Theme
* nsNativeThemeCocoa : public ThemeCocoa
* nsNativeThemeWin : public Theme
* nsNativeThemeGtk : public Theme
Differential Revision: https://phabricator.services.mozilla.com/D135668
This allows MSIX-installed Firefox to be launched through Win+r and Powershell (and probably other places). This feels deceptively simple - but it appears to work.
Differential Revision: https://phabricator.services.mozilla.com/D135638
nsPresContest::RegisterManagedPostRefreshObserver still lets us add a managed post refresh observer until the mPresShell pointer on the prescontent is nulled out. That means that between the call to CancelManagedPostRefreshObservers and mPresContext->DetachPresShell() (which nulls out the mPresShell pointer on the prescontext) in PresShell::Destroy we can add a managed post refresh observer that will never get removed. Notably, destroying the frame tree happens between these two calls.
So move the CancelManagedPostRefreshObservers call to happen right after we null out the mPresShell pointer on the prescontext.
In bug 1737503 I want to add a managed post refresh observer when we destroy a subdocument frame (it's only interested in the recreate frames case not the destruction case, but not an easy way to tell them apart afaik), so it triggers this bug. The patch and test I have for that bug exercise this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135340
Alexandre Lissy
Butkovits Atila
Brad Werth
Randell Jesup
stransky
Tom Schuster
Chris Martin
Neil Deakin
Nicolas Chevobbe
Agi Sferro
Ting-Yu Lin
Marian-Vasile Laza
Emilio Cobos Álvarez
Hannah Peuckmann
Barret Rennie
Jamie Nicol
Katherine Patenio
Joel Maher
Ben Hearsum
Dzmitry Malyshau
Gabriele Svelto
Olli Pettay
Jens Stutte
Hubert Boma Manilla
Edgar Chen
Cristian Tuns
Alexandre Poirot
Shelly Lin
Julien Cristau
Sebastian Hengst
criss
Timothy Nikkel