Full Firefox on Linux can now be run with a --headless flag.
This includes seven parts:
1) Running all marionette tests in headless mode.
2) Prevents crashes where Firefox calls into GTK.
3) Adds a headless screen helper which supports changing the headless
screen size with the environment variables MOZ_HEADLESS_WIDTH and
MOZ_HEADLESS_HEIGHT.
4) Supports simulating moving a headless window.
5) Adds a stubbed out nsSound implementation.
6) Supports simulating size mode changes of headless windows.
7) Adds the --headless flag for Firefox.
This simplifies plumbing it through mozharness for automated testing, because
mozharness doesn't already have the ability to set prefs for all the different
kinds of test suites. It can set environment variables though.
MozReview-Commit-ID: BdsH09WTqO4
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
We were only reporting the WR feature state in crash reports from the parent
process. However, it would be useful to have in GPU and content process crash
reports as well, so use the ScopedGfxFeatureReporter in those processes as well.
MozReview-Commit-ID: Em37uLVPboK
--HG--
extra : rebase_source : c5bae376d084b7579308dcf1f5fb6186a231a868
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
Supports creating a windowless browser on Linux without an X server. Most of the
changes are just adding branches to avoid calls in to GTK which calls
into X. Some of the bigger additions were adding a separate headless widget
which implements just enough to render a page. A headless look and
feel were also added since there are many calls into GTK in the platform
specific one.
nsIFontEnumerator::GetDefaultFont() returns always nullptr. However, it's used in font setting UI at creating drop down list of available fonts. So, if we implement this as returning first available font of "font.name-list.*", it's what is the necessary UI for "default" font when "font.name.*" is empty string.
So, with this patch, the top item of font list becomes "Default (%s)" if there is available font.
MozReview-Commit-ID: cRU8gixgdF
--HG--
extra : rebase_source : beca7b7d2d423f08d35358fc84b731e817724835
This will add "WR?" if the pref is not set to true, or "WR!" if the pref is set
to true (which indicates the user flipped it), followed by "WR+" or "WR-" which
indicates whether or not WebRender is enabled.
MozReview-Commit-ID: F3h5UowCxij
--HG--
extra : rebase_source : e809a9026c35d89c101e6cb72d09cd6136ed84c6
gfxWindowsPlatform overrides InitAcceleration, and the override calls
InitGPUProcessSupport, which may disable the GPU process. Therefore, in
order to capture this scenario, we need to initialize WebRender after
the subclass implementation has run, rather than at the end of the base
class implementation, which is before InitGPUProcessSupport has run.
This adds back a MOZ_ENABLE_WEBRENDER define, which only controls whether or
not WebRender is enabled at runtime. The default behaviour is changed so that:
- if the user specifies --disable-webrender in the mozconfig, WebRender is
neither built nor enabled
- if the user specifies --enable-webrender in the mozconfig, WebRender is
built and enabled
- if the user specifies --enable-webrender=build in the mozconfig, WebRender is
built but not enabled, except on Android where it is neither built nor enabled
- if the user doesn't specify any of the above, the default behaviour is:
- on nightly/local builds, the same as --enable-webrender=build
- on other channels (e.g. aurora), the same as --disable-webrender
The net effect is that local/Nightly-automation builds will have WebRender
built-in but not enabled where possible (i.e. not Android). However the user
can override this behaviour via mozconfig options to either not build WebRender
at all, or to enable it in addition to building it.
MozReview-Commit-ID: IM7DdSHkIB
Instead of just reporting the value of the pref, also make sure that about:support
incorporates the runtime check of whether or not a touch device was discovered
in the widget code. The code to do this already exists in TouchEvent::PrefEnabled,
so we can just reuse that.
MozReview-Commit-ID: DN7FSlsDwD1
--HG--
extra : rebase_source : efb3d66e1669f8f2b038888ef2b1c8bb83f1c710
Wes Kocher
Alexis Beingessner
Sebastian Hengst
Andrew Osmond
domfarolino@gmail.com
Mason Chang
Jeff Muizelaar
Jonathan Kew
Brendan Dahl
Morris Tseng
Kartikaya Gupta
Gerald Squelart
David Anderson
David Anderson
Nicholas Nethercote
Randall Barker
Jay Harris
Lee Salzman
Masayuki Nakano
Sotaro Ikeda
Nicolas Silva
sotaro
Boris Zbarsky
Zibi Braniecki
Sylvestre Ledru
Ryan Hunt