Win32k is required for moz-icon in the file content process and we don't want to
block enabling for web content processes on this and other uses that may only be
in the file content process.
Differential Revision: https://phabricator.services.mozilla.com/D112960
In bug 1680087 we disabled webrender's partial present feature on
Mali-T6xx and T7xx devices due to rendering issues caused by a buggy
implementation in the driver. We have now seen reports of the same
issue on a Mali-T8xx device.
This patch expands the block to include all Mali-Txxx devices. As a
follow up we should make this dependent on the driver version, so
that users with working drivers can take advantage of the feature.
Differential Revision: https://phabricator.services.mozilla.com/D113477
We have code for this, it's disabled for elements that are 90% or greater the width of the viewport. This code was added in bug 1204084 for the "double tap on tall element" problem and the 90% hasn't been touched since. I can't think of a good reason why we would want to scroll to the top of the element if its 90% the width of the viewport or more.
Differential Revision: https://phabricator.services.mozilla.com/D113335
This fixes the issue for me. I can't think of any problems with doing this
here? However I am not an expert in the remote service. As part of this I also
cover the case where the user encounters the profile lock dialogue and selects
to kill the existing instance of Firefox. This can result in a slow startup in
a similar way as far as I've been able to observe.
Differential Revision: https://phabricator.services.mozilla.com/D113054
Bug 1613798 (shutdown crashes during ChildProfilerController::ShutdownAndMaybeGrabShutdownProfileFirst's nsThread::Shutdown) could be explained by another nested shutdown destroying the same thread first, so when coming back to the first inner loop, there's a UAF on the already-destroyed thread!
Now we first reset the `mThread` pointer so it cannot be used by later/nested function calls, but keep a local reference (which should be the last one) to dispatch the shutdown operations and then shutdown the thread itself.
Also the thread pointer is now encapsulated in a DataMutex, in case it is accessed from different threads (e.g., the main thread and the IPC reception thread.)
Differential Revision: https://phabricator.services.mozilla.com/D113304
This reverses a decision that was made in the original design of Normandy's preference experiments. That decision was made assuming simple experiments that only change one preference.
Today, preferences are more complicated, have more interactions, and often change more than one preferences. Unenrolling users from experiments due to preferences changing causes bugs, unexpected experiences for users, and bad experiment outcomes.
This change will make Normandy act more in alignment with how experimenter owners and data analysts already treat it, improving the overall experience of the experiments program.
Differential Revision: https://phabricator.services.mozilla.com/D112070
On CI, where we open and close menu items in quick succession, we sometimes got
into a state where the new menu was opened while we were still in the old menu's
nested event loop. So we had the following sequence of events:
```
- old menu +[NSMenu popUpContextMenu:withEvent:forView:]
- nested event loop for old menu
- old menu -[NSMenu cancelTrackingWithoutAnimation]
- new menu +[NSMenu popUpContextMenu:withEvent:forView:]
- nested event loop for new menu
- new menu -[NSMenu cancelTrackingWithoutAnimation]
- new menu's event loop is exited, but old menu's event loop remains on the
stack
- shutdown hang here
```
MOZMenuOpeningCoordinator makes sure that +[NSMenu popUpContextMenu:withEvent:forView:]
is always called in sequence, never in a nested fashion.
Differential Revision: https://phabricator.services.mozilla.com/D113373
XPCOM complains when events are dispatched during shutdown. Since we're
shutting down, there's no really any point in dispatching these messages
anyway, so we can safely ignore them.
Differential Revision: https://phabricator.services.mozilla.com/D113203
Marionette uses GVE and sometimes closes the last tab and calls |Quit| at the
same time. When the last tab is closed, GVE will try to open a new tab with the
same content in it, to avoid leaving the browser in the "zero tabs" state. This
causes a race condition where the browser is shutting down and a new tab is
being created, which trips an assertion in our widget code.
During real life usage of the browser, calling Quit only happens during errors.
Because of that, and the fact that we're not seing this crash in the wild,
it should be safe to just fix the problem in GVE instead of supporting this
edge case in GeckoView.
To support the Marionette case, we allow GVE to stay at zero tabs. Some menu
elements need to be disabled (like reload tab and the url bar).
This has the added benefit of being able to test the "no windows" case in GVE
which wasn't possible until now.
Differential Revision: https://phabricator.services.mozilla.com/D113202
We've been using 3 on Nightly for a long time without
any problems and it's generally much better to keep the GPU
process around than give up on it.
We also bump the Nightly value to increase the chances of us
finding any problems where we should give up on using the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D113393
