When compositor session exists, gfxConfig is already initialized.
If first AppWindow is destroyed in nsAppShellService::JustCreateTopWindow() because of error, the first window could be destroyed before calling gfxConfig::Init(). gfxConfig::Init() is called from gfxPlatform::GetPlatform(). gfxPlatform::GetPlatform() is called just before creating compositor by nsBaseWidget::CreateCompositor()
Differential Revision: https://phabricator.services.mozilla.com/D160453
It was made a bitfield so that we could include style. But then style
containment was removed and the bitfield keeps causing us to do wrong
check (since INLINE_SIZE intersects SIZE).
So just make it an enum. This causes a progression and a test that
failed now times out (which is a pre-existing issue, just like the
pseudo-elements test that times out).
Differential Revision: https://phabricator.services.mozilla.com/D160371
Bug 1765835 has fixed enableHighAccuracy issue for all platforms, but its test
is on GeckoView only. So I would like to add this test for desktop.
Differential Revision: https://phabricator.services.mozilla.com/D160350
This changes the first thing that appears on treeherder from a generic
gmake[4]: *** [/builds/worker/checkouts/gecko/config/makefiles/rust.mk:433: force-cargo-library-build] Error 101
to a more useful (e.g.)
[style 0.0.1] thread 'main' panicked at 'Not able to resolve vector element?: Continue', /builds/worker/checkouts/gecko/third_party/rust/bindgen/src/ir/ty.rs:1135:22
Differential Revision: https://phabricator.services.mozilla.com/D160442
In bug 1772839 we were seeing a large number of crashes due to
encountering a webrender error after exhausting all fallback
configurations. At least in some cases, this was due to the compositor
being resumed with an Android Surface that was already in an abandoned
state, meaning we can never succeed in creating an EGL Surface.
We added a check for this condition, and a workaround, to the
GeckoView java code. However, we are still seeing crash reports
matching this signature. To help determine whether these are also due
to the Surface being abandoned, or due to some other reason, this
patch adds a deliberate crash much earlier in the pipeline if we
detect an abandoned Surface.
Differential Revision: https://phabricator.services.mozilla.com/D160042
Existing tests are updated so they pass with this change, and a specific
test case is added to make sure that adding midi-sysex permission does
not automatically add permission to midi.
Differential Revision: https://phabricator.services.mozilla.com/D160370
be -> d23055b85e70fb152749fb0d36b21fa4825f4910
ia -> 354609b8814d82b3ad8730efeecce6a35324d878
it -> 06e4c437dfcdf02cbb7d5640fc463aa9f3e5962c
ko -> ad2005b7cc644557633febfbd536b2ec027f9e25
tg -> b8a5673f3beeda0f011d060610fda8900c5bde12
zh-CN -> 4883f2421d2a487d435f132e71100847a6983d4e
`PushServiceAndroidGCM` is Fennec only module and GeckoView uses
`GeckoViewPush.jsm` for push service. So we should get rid of
`PushServiceAndroidGCM`.
Differential Revision: https://phabricator.services.mozilla.com/D160351
Ensure that when we evaluate the downloadable blocklist, we actually
only use the downloadable blocklist. We should not include any platform
specific checks in these prefs, as it causes confusion about why the
prefs were set in the first place. Allowlisted features should be
ignored when evaluating the downloadable blocklist; if we wish to
override the ALLOW/ALLOW_QUALIFIED/DENIED statuses, we should use OK or
BLOCKED_DEVICE or similar instead.
This caused allowlisted features (like WebRender) to be taken away from
users in the most recent nightly.
Differential Revision: https://phabricator.services.mozilla.com/D160408
The fix for bug 1759555 involves having rust-analyzer invoke `mach`.
However, `mach` can't be executed directly on Windows systems -- it's a
Python script, not an executable, and so `::CreateProcessW` has no idea
what to do with it.
Work around this by having `mach` explicitly direct `rust-analyzer` to
use `sys.executable` to execute `mach`.
Differential Revision: https://phabricator.services.mozilla.com/D160306
If we get via OnFrameChanging, we compute a new sizemode, but never store it on
the widget, yet we notify that it has changed.
We were relying on a call to mWindow->SetSizeMode from the widget delegate
which I removed in:
c9785cd100
Instead, call EnsureSizeMode to make sure we already have the right sizemode
when notifying our listener.
Differential Revision: https://phabricator.services.mozilla.com/D160365
I saw something like a 5% improvement to the Elm, React, and React-Redux
subtests of speedometer with this, with maybe a 1% overall Speedometer
improvement, although the confidence is lower.
Differential Revision: https://phabricator.services.mozilla.com/D158983
Big hack, but this ensures that the dialog is at the right position when it's a
subdialog positioned by the front-end... Otherwise we fire this before setting
the vertical margin in the opener, and sadness ensues.
I'd try to find a nicer solution to this, but:
* This is the easiest that is potentially upliftable.
* I'm a bit swamped with some other work.
* This is an extra one-liner, for a very niche feature.
Differential Revision: https://phabricator.services.mozilla.com/D160420
We noticed this while looking at the CacheIR generated for an add-slot stub.
The depth threshold of 4 was picked by browsing around on the web and dumping the observed depth. 4 is enough to cover 95%+ of the cases I saw.
There are a couple of other places where we use LoadProto: the no-teleporting case in `GeneratePrototypeGuards`, and `ShapeGuardPrototypeChainForCrossCompartmentHolder`. They didn't show up in my experiments, so I left them alone for now.
Differential Revision: https://phabricator.services.mozilla.com/D158037
If we get via OnFrameChanging, we compute a new sizemode, but never store it on
the widget, yet we notify that it has changed.
We were relying on a call to mWindow->SetSizeMode from the widget delegate
which I removed in:
c9785cd100
Instead, call EnsureSizeMode to make sure we already have the right sizemode
when notifying our listener.
Differential Revision: https://phabricator.services.mozilla.com/D160365
