Currently, there is an outstanding issue where enabling the GPU sandbox breaks
scrolling using the the mouse wheel on laptops with Intel GPUs.
This will enable the GPU sandbox on Nightly for non-Intel GPUs to prevent any
sandbox regressions while we try and figure out what the scrolling issue is.
See Bug 1630860 for more info
Differential Revision: https://phabricator.services.mozilla.com/D73923
When the browser process starts a sandbox process, we copy the executable's IAT
for ntdll.dll into the new process to prevent DLL injection via IAT tampering as
the launcher process does. However, if IAT has been modified by a module injected
via `SetWindowHookEx`, the browser process cannot copy IAT because a modified IAT
is invalid in a different process, failing to start any sandbox processes.
The proposed fix is to cache IAT before COM initialization which may load
modules via `SetWindowHookEx` for the first time in the process.
Differential Revision: https://phabricator.services.mozilla.com/D73303
Add importableLogins autocomplete items that show for a site when there's chromium-based logins, no saved logins, and appropriate experiment state. Default behavior is unchanged with default "" pref value, and new behavior can be turned on with "import" pref value.
Differential Revision: https://phabricator.services.mozilla.com/D72096
* Add a new `allowSearchSuggestions` property to the query context. It defaults to true.
* `UrlbarInput` sets this property when it starts a query. If the event that started the query is a paste event and the pasted string's length is larger than maxChars, then don't allow suggestions. Otherwise do.
* `UrlbarProviderSearchSuggestions.isActive` returns false when `!context.allowSearchSuggestions`.
* `UrlbarProviderSearchSuggestions` doesn't truncate the query anymore.
* Keep the `browser.urlbar.maxCharsForSearchSuggestions` pref but use it only for pastes, and increase it from 20 to 100. I considered making a new pref but this way if a user changed it, then it still applies to pastes at least. I'm not sure it's important though.
Differential Revision: https://phabricator.services.mozilla.com/D70956
This patch introduces a new tab modal system prompt type. It can be opened via the nsIPromptService
with a destination BrowsingContext. These tab system prompts overlap slightly with the upper
chrome UI to differentiate them from content prompts (previously called tab prompts).
- Extended nsIPromptService and nsIPrompt to accept 3 types of modal prompts:
- Window prompts
- Tab (system) prompts
- Content prompts (the old tab prompts)
- Removed prompt code from Prompter.jsm, always call PromptParent window actor instead
- Added PromptChild window actor to forward pagehide events to parent actor
- Created additional prompt methods in nsIPromptService to prompt by browsingContext and modalType
- Backwards compatibility is maintained, consumers can still open content prompts calling nsIPrompt with a content window
Differential Revision: https://phabricator.services.mozilla.com/D66446
The changes that are being removed now were introduced as a Fission-compatible approach in Bug 1572651, but were made obsolete by the fact that `setupInParent()` will not get a Fission-compatible replacement under the hood.
The replacement box model highlighter is implemented in Bug 1598307.
Most of the changes are removed aside from `server/actors/highlighters/box-model-renderer.js` which is the subset of code from `server/actors/highlighters/boxmodel.js` that handles only the rendering of the highlighter markup. This is reused in the upcoming replacement (see D54022).
Differential Revision: https://phabricator.services.mozilla.com/D69833
It seems that all the warnings caused by the GPU sandbox have been fixed, and
the transparent window issue was resolved in D61370.
Hopefully there are no further complications and this can stay landed.
Differential Revision: https://phabricator.services.mozilla.com/D18876
--HG--
extra : moz-landing-system : lando