Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
The BrowserParent's IPC receive methods for nsIWebProgress events in the
BrowserChild were all doing the same set up to ensure they had the correct
state to process them. This has now been refactored out into a single method.
Differential Revision: https://phabricator.services.mozilla.com/D30730
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
Whenever we switch processes in GeckoView we didn't inject frameScripts.
This change adds a new method `loadInitFrameScript` that is called whenever a
module's new browser is attached to a window so that the frame script is loaded
correctly into the new browser.
This fixes a bug in WebExtension pages where the WebExtension Process Script
would never be notified of a new WebExtension page window, breaking privileged
APIs.
Differential Revision: https://phabricator.services.mozilla.com/D32148
--HG--
extra : moz-landing-system : lando
WebExtension can always open their respective WebExtension pages even when the
WebExtension page is not content accessible.
However, this is not true for `tabs.update`, which couldn't link to
WebExtension pages at all.
Similarly, a user should be able to open a WebExtension page directly by typing
the URL.
To fix the above problems we pass the correct `triggeringPrincipal` when
loading such URIs. This change also makes URI typed by the user not use the
`systemPrincipal` anymore but a more restrictive codebase principal local to
the page that's being typed to avoid unintended side-effects. This also makes
the triggering URI always the page for these privileged pages, so we need to
adjust some tests to account for that by loading unprivileged `http` pages
instead.
Differential Revision: https://phabricator.services.mozilla.com/D32149
--HG--
extra : moz-landing-system : lando
The new trace logger spew routines do not have a corresponding empty inline version for when --disable-trace-logging is used.
Differential Revision: https://phabricator.services.mozilla.com/D32156
--HG--
extra : moz-landing-system : lando
It makes more sense to declare the preference changes in the root
React component, as other components (aboutdebugging, netmonitor, ...)
already do it.
Since we don't want to unmount the App component (which means we
won't fire any componentWillUnmount), we're turning the observer
into a weak referenced one so we don't leak.
Differential Revision: https://phabricator.services.mozilla.com/D31591
--HG--
extra : moz-landing-system : lando
It was introduced in bug 1352096 to reduce complexity with Stylo (apparently).
Right now it doesn't look like it reduces any complexity, and it's a bit
annoying with some of the patches that I'm writing at the moment.
So unless there's any objection I think it should go away.
Differential Revision: https://phabricator.services.mozilla.com/D31708
--HG--
extra : moz-landing-system : lando
With WebRender, we had observed that the print preview for animated
images was not displaying correctly. It should display the first frame
but it was showing nothing the first time the preview was opened. Once
the decoded image was available in the cache, it would display
correctly if the preview was reloaded.
The StartDecoding and RequestDecode variants always requested
FRAME_CURRENT for animated images. They should use FRAME_FIRST for
static requests / FrozenImage. Correcting this fixes the print preview.
Differential Revision: https://phabricator.services.mozilla.com/D32033
Don't hold gMutex when calling HandleSharePortsMessage() from PortServerThread to avoid deadlock.
Differential Revision: https://phabricator.services.mozilla.com/D31694
--HG--
extra : moz-landing-system : lando
This patch implements the new stub installer UI design for the official branding
and leaves the other brandings mostly alone. Leaving them entirely alone was not
a goal because it wouldn't have been worth the hacks required, but the layouts
and overall designs should be unchanged. The differences between the two designs
are intended to be driven entirely by the branding files, so that the new design
can be easily expanded to the other channels once art assets exist.
Depends on D31145
Differential Revision: https://phabricator.services.mozilla.com/D31146
--HG--
extra : moz-landing-system : lando
This patch adds a bunch of new defines for stub installer UI parameters that
were previously hard coded or implicit, moves several that were universal into
the branding files, removes several no longer used ones, and changes the names
of some others to match a standard naming convention.
Depends on D31144
Differential Revision: https://phabricator.services.mozilla.com/D31145
--HG--
extra : moz-landing-system : lando
We used to use 2 rAFs to stop the load event from racing with
onmessage event, but this was not the proper solution and it was
still racy, especially after Bug 1534012 is landed. So we fixed it
by instead letting racy postMessage to be sent, we wait for the
proper postMessage to be sent, and the test would automatically
timeout if the proper postMessage failed to sent.
Differential Revision: https://phabricator.services.mozilla.com/D32029
--HG--
extra : moz-landing-system : lando
MALLOC_STATIC_PAGESIZE is only set on some platforms. Specifically, it's
not set on ia64 and sparc. Which means the case MALLOC_STATIC_PAGESIZE
&& (sparc || ia64) never happens, and gPageSize is never 8 KiB.
Differential Revision: https://phabricator.services.mozilla.com/D31965
--HG--
extra : moz-landing-system : lando
This will save us some time from figuring out what's the best thing to do in
bug 1552587, so that other patches I have in flight (mainly bug 1552708) can
land, since we cannot add a single byte to nsStyleDisplay right now otherwise.
The code removed here is well isolated and not that complicated, so it seems to
me that should be easy to bring back should we have an emergency (and I commit
to doing that while preserving the nsStyleDisplay size limit if we need to :)).
Differential Revision: https://phabricator.services.mozilla.com/D32026
--HG--
extra : moz-landing-system : lando
