When already_AddRefed is destroyed, mRawPtr of already_AddRefed needs to be cleared. But when SerializedTaskDispatcher was already destroyed, mRawPtr of already_AddRefed<nsIRunnable> was not cleared.
Differential Revision: https://phabricator.services.mozilla.com/D140012
From https://w3c.github.io/screen-orientation/#apply-an-orientation-lock
> 7.2. Apply an orientation lock
>
> The steps to apply an orientation lock to a Document using orientation are as
> follows:
>
> 1. If the user agent does not support locking the screen orientation, return
> a promise rejected with a "NotSupportedError" DOMException and abort
> these steps.
So if orientation controller delegate isn't set, we should throw
`NotSupportedError`. But, actually, we throws `AbortError`, so this isn't
correct.
To return any DOM error from platform implementation of
`screen.orientation.lock`, I would like to change return value to
`GenericPromise`'s.
Differential Revision: https://phabricator.services.mozilla.com/D137970
We noticed a cold_view_nav_start regression on Fenix from enabling the
GPU process, and profiles showed time spent synchronously waiting for
the GPU process to launch. This occured because the compositor was
being created in nsWindow::Create, and as it requires the GPU process
to be running it had to block until launch completed. The process is
launched when the gfxPlatform is first initialized, but that was only
occuring immediately prior to creating the compositor, which did not
give it enough time to complete asynchronously.
This patch makes it so that we initialize the gfxPlatform slightly
earlier, and importantly delay creating the compositor until it is
actually required. This gives the process enough time to launch
asynchronously meaning we do not have to block.
We started deliberately creating the compositor early on Android
because of bug 1453501, to avoid a race condition where the compositor
didn't exist when RemoteLayerTreeOwner::Initialize was called, causing
us to use a basic layer manager. However, since bug 1741156 landed we
now create the compositor on-demand, meaning this is no longer a
possibility.
Delaying compositor creation can, however, uncover another race
condition. If the UICompositorControllerChild is opened on the UI
thread before the main thread is able to set its pointer to the
widget, then the java GeckoSession will never be notified that the
compositor has been opened, and composition will never be
resumed. This patch fixes this issue by setting the
UiCompositorControllerChild's widget pointer in its constructor rather
than immediately afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D139842
I couldn't see any value in running these for private and non-private mode, since all of those differences are up in Javascript land.
Differential Revision: https://phabricator.services.mozilla.com/D139608
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
The overarching change here is that it's now possible to get an AUMID without first trying to fetch the current one that's set -- this allows us to obtain the Private Browsing one from a non-Private window, which we will need in a later patch to supporting adding a Private Browsing taskbar pin during onboarding.
Differential Revision: https://phabricator.services.mozilla.com/D138193
DevicePixelsToGdkRectRoundOut should have the same behavior here and is
simpler / less weird than having a positionless rect variable to
represent a size.
Depends on D139623
Differential Revision: https://phabricator.services.mozilla.com/D139672
Store preferred rect in dev pixels, which simplifies a bit other calculations,
and ensures that the nsMenuPopupFrame code accounts for zoom etc.
Use existing conversion methods for GDK <-> Device <-> CSS conversions.
Differential Revision: https://phabricator.services.mozilla.com/D139623
The changes in this patch stack will change how IPDL generated files are built,
such that these issues are now surfaced, especially during non-unified builds.
Differential Revision: https://phabricator.services.mozilla.com/D137165
It looks like it was added to abstract commonalities between Win32 and
WinRT. But we dropped support for WinRT a long time ago, and there hasn't been
any work on this area of code in 8 years. In the meantime, it just adds an
extra layer of indirection that doesn't need to exist.
Differential Revision: https://phabricator.services.mozilla.com/D139771
I had this written somewhere in a branch, but given bug 1419151, I
cleaned it up a bit and turned it into an actual patch that works.
Behind a pref for now, because at the very least it needs:
* Support for some testing-only functions.
* Support for custom icons (for web extensions and so on).
The key point is that this adds the relevant code to map a XUL menu to a
GMenuModel, which we could then export via
`g_dbus_connection_export_menu_model()`, which seems like a much simpler
approach to support stuff like bug 1419151.
See the MenuModel class in NativeMenuGtk as for how is this done.
Differential Revision: https://phabricator.services.mozilla.com/D139845
We no longer need to use the print portal, the gtk is doing that for us
for the system print dialog and the native print dialog uses GtkPrintJob
which sends jobs to the cups print backend.
Differential Revision: https://phabricator.services.mozilla.com/D139594
I couldn't see any value in running these for private and non-private mode, since all of those differences are up in Javascript land.
Differential Revision: https://phabricator.services.mozilla.com/D139608
This is subject to the same issue as an earlier patch in this series -- the icon will be wrong briefly at first launch, before the code in `BrowserContentHandler.jsm` replaces the default icon with the correct one.
Differential Revision: https://phabricator.services.mozilla.com/D138601
This is done differently depending on whether the Private Browsing window is the initial one, or if it's a new window from a running application. In the former case, we're still not setting it up early enough -- the window will initially show up in one icon, and then switch to the other one after we've adjusted the AUMID.
Regardless, the fact that we're doing it for every new window appears to mean that other places that require it (such as GeckoChildProcessHost.cpp) will Do The Right Thing (because they'll pull the cached version that `GetAppUserModelID` finds).
This behind a pref for now both because of the issue noted above, as well as the fact that we're waiting on finalized branding for this.
Differential Revision: https://phabricator.services.mozilla.com/D138194
The overarching change here is that it's now possible to get an AUMID without first trying to fetch the current one that's set -- this allows us to obtain the Private Browsing one from a non-Private window, which we will need in a later patch to supporting adding a Private Browsing taskbar pin during onboarding.
Differential Revision: https://phabricator.services.mozilla.com/D138193
