The new section is displayed when the browser.enableAboutThirdParty pref is true.
This is a prototype of the project where we plan to disclose third-party modules
info to the users. Once we find out what is the best place and the best way to
show these data, we remove this section.
Differential Revision: https://phabricator.services.mozilla.com/D93832
The new section is displayed when the browser.enableAboutThirdParty pref is true.
This is a prototype of the project where we plan to disclose third-party modules
info to the users. Once we find out what is the best place and the best way to
show these data, we remove this section.
Differential Revision: https://phabricator.services.mozilla.com/D93832
This adds Locale to MozIntl and uses it to replaces some instances where we
used regular expressions to parse language tags. It is based on work done by
André Bargull in Bug 1639515.
Differential Revision: https://phabricator.services.mozilla.com/D98393
This adds Locale to MozIntl and uses it to replaces some instances where we
used regular expressions to parse language tags. It is based on work done by
André Bargull in Bug 1639515.
Depends on D98392
Differential Revision: https://phabricator.services.mozilla.com/D98393
This commit adds a rosetta status to three different places:
- `nsSystemInfo`, to check for rosetta status per apple specifications. We also use the same check in `nsCocoaFeatures` in D89961.
- `Troubleshoot.jsm`, to add rosetta status data (should it exist) to use in about:support
- `About:Support` itself, if the device is running MacOS
Differential Revision: https://phabricator.services.mozilla.com/D94930
This commit adds a rosetta status to three different places:
- `nsSystemInfo`, to check for rosetta status per apple specifications. We also use the same check in `nsCocoaFeatures` in D89961.
- `Troubleshoot.jsm`, to add rosetta status data (should it exist) to use in about:support
- `About:Support` itself, if the device is running MacOS
Differential Revision: https://phabricator.services.mozilla.com/D94930
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
This formed the backbone of the previous process switching codepath, and
shouldn't be necessary anymore thanks to DocumentChannel's new codepath.
This also removes the eager process switching logic from frontend's _loadURI, as
it would rarely be taken, unless an invalid URI was entered, already.
Differential Revision: https://phabricator.services.mozilla.com/D94639
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
This moves callers that are using getLocaleInfo to determine the current locale
to render widgets to use the new isAppLocaleRTL method. This will allow us to remove
pref overrides from getLocaleInfo.
Differential Revision: https://phabricator.services.mozilla.com/D96234
This small tweak makes it ergonomic to remove variables from the
inherited environment. Using `null` to signal "removal", distinct
from `undefined` for "ignored", seems to be an accepted idiom in these
types of JS interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D95896
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
This formed the backbone of the previous process switching codepath, and
shouldn't be necessary anymore thanks to DocumentChannel's new codepath.
This also removes the eager process switching logic from frontend's _loadURI, as
it would rarely be taken, unless an invalid URI was entered, already.
Differential Revision: https://phabricator.services.mozilla.com/D94639
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
- Expose wayland dmabuf related options, which are:
widget.dmabuf-textures.enabled
widget.dmabuf-webgl.enabled
- Expose widget.use-xdg-desktop-portal which enables remote system dialogs like Print/Open/Save.
- Expose general Wayland preferences:
widget.wayland-smooth-rendering - extra buffering of Wayland SW rendering
widget.wayland.use-opaque-region - use transparency hints for Wayland compositor
widget.wayland_vsync.enabled - use independent vsync source
None of them provide sensitive informations.
Differential Revision: https://phabricator.services.mozilla.com/D86939
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
Using `visibility` preserves frames of the content inside the dialog,
which we rely on to print the preview `<browser>` element.
This was working before bug 1662336 mostly by chance, because we were
doing an extra clone and that happened to mostly not rely on the cloned
document being rendered.
I'd rather fix it in the front-end (by not trying to print a
`display: none` <browser>) than going back to do a separate clone,
because that can get expensive (specially with fission).
It's not super-clear to me how to best test the "print from system
dialog" case, but ideas certainly welcome.
Differential Revision: https://phabricator.services.mozilla.com/D95501
This patch uses (and somewhat abuses) the existing PromiseTestUtils
mechanism to also be able to whitelist uncaught errors that are not
actual Promise rejections.
This uses `ChromeUtils.recentJSDevError`, which lets us find out
whether there is a recent ReferenceError/SyntaxError/TypeError in
chrome code, even if that error was caught.
MozReview-Commit-ID: 5z1pffURNYm
Differential Revision: https://phabricator.services.mozilla.com/D94972
Toshihito Kikuchi
Narcis Beleuzu
Scott
Csoregi Natalia
Sam Foster
Dan Minor
Brindusan Cristian
Dale Harvey
Razvan Maries
Kris Wright
pbz
Nika Layzell
Bogdan Tara
Dão Gottwald
Tim Huang
Mihai Alexandru Michis
Kris Maglione
Nick Alexander
Neil Deakin
Emilio Cobos Álvarez
Martin Stransky
Dorel Luca
Tim Giles
Marco Bonardo
David Teller