We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
It's a security risk such that the maximized external program can obscure
the fullscreen notification and the malicious site can use this trick
to load a spoofed page in the background without user notices it.
This patch minimized the risk by always exit the fullscreen mode when
an external protocol is triggered.
Differential Revision: https://phabricator.services.mozilla.com/D177771
It's a security risk such that the maximized external program can obscure
the fullscreen notification and the malicious site can use this trick
to load a spoofed page in the background without user notices it.
This patch minimized the risk by always exit the fullscreen mode when
an external protocol is triggered.
Differential Revision: https://phabricator.services.mozilla.com/D177771
This comes from bug 890195, and it was superseded by bug 1575097.
This isn't used for anything anymore, and we can remove the otherwise unused
MediaFeatureChangeReason flag as well.
Differential Revision: https://phabricator.services.mozilla.com/D174492
These types were already non-nullable, with the serializer implementation not
supporting nullptr values. This patch converts the uses to be explicitly
non-nullable, and adds the relevant `WrapNotNull` changes.
Differential Revision: https://phabricator.services.mozilla.com/D168890
This makes various changes to the named lookup/navigation code to make
them more precise, and avoid issues which could happen if a window is
closed while script is still executing.
This also should improve handling for inactive windows in some cases, by
more frequently working off of the WindowContext tree rather than the
BrowsingContext tree.
As part of these changes, some behaviour was changed around e.g. the
file URI exception to avoid the deprecated nsIPrincipal::GetURI method.
I don't believe the behaviour should have changed in a meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D171755
These types were already non-nullable, with the serializer implementation not
supporting nullptr values. This patch converts the uses to be explicitly
non-nullable, and adds the relevant `WrapNotNull` changes.
Differential Revision: https://phabricator.services.mozilla.com/D168890
This makes various changes to the named lookup/navigation code to make
them more precise, and avoid issues which could happen if a window is
closed while script is still executing.
This also should improve handling for inactive windows in some cases, by
more frequently working off of the WindowContext tree rather than the
BrowsingContext tree.
As part of these changes, some behaviour was changed around e.g. the
file URI exception to avoid the deprecated nsIPrincipal::GetURI method.
I don't believe the behaviour should have changed in a meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D171755
BrowsingContext::ShouldAddEntryForRefresh expects to be passed the current URI,
to determine if it's the same as the URI for the new load (we shouldn't add a
new entry if they are the same). Before this patch, in the child process we call
BrowsingContext::ShouldAddEntryForRefresh from nsDocShell::MoveLoadingToActiveEntry
(nsDocShell::CreateContentViewer -> Embed -> MoveLoadingToActiveEntry), passing
nsDocShell's mCurrentURI. However, by that point nsDocShell::CreateContentViewer
has already set the mCurrentURI to the newly loading URI (through
nsDocShell::OnNewURI). In the parent process we do pass the correct URI to
BrowsingContext::ShouldAddEntryForRefresh, so the session history ends up being
correct, but depending on timing of the IPC messages there's a brief moment where
index and length are incorrect in the child process (child process and parent
process get a different answer from BrowsingContext::ShouldAddEntryForRefresh).
This causes intermittent failures in the test at
docshell/test/mochitest/test_bug1742865.html.
Differential Revision: https://phabricator.services.mozilla.com/D169544
We'd return early anyhow later in nsDocShell::InternalLoad.
The patch is based on code inspection. If one is closing the window while printing, we could get to this state, among other cases.
Differential Revision: https://phabricator.services.mozilla.com/D168368
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
Implementations of nsIEmbeddingSiteWindow and nsIBaseWindow largely
overlap, and where they don't, the nsIEmbeddingSiteWindow implementation
of the otherwise shared interface is primarily stubbed out with the
exception of Get/SetDimensions().
This patch moves a reimplementation of Get/SetDimensions() from
nsIEmbeddingSiteWindow to nsIBaseWindow. The other methods of
nsIEmbeddingSiteWindow remain covered by nsIBaseWindow.
Get/SetDimensions() can be implemented as part of nsIWebBrowserChrome
where nsIBaseWindow is not necessary. This removes the need for
nsIEmbeddingSiteWindow.
Blur() has also been moved to nsIWebBrowserChrome, as only
nsContentTreeOwner has an actual implementation which we in theory also
want to call from BrowserChild/Parent, but the spec suggests to
"selectively or uniformly ignore calls".
GetVisibility() had an implementation in BrowserChild that pretended to
always be visible. Instead of providing an interface for that,
nsDocShell now handles the not implemented case for tree owners.
nsIEmbeddingSiteWindow::GetSiteWindow() used to call through to
nsIBaseWindow::GetParentNativeWindow().
The Get/SetDimensions() implementation has been replaced with a strongly
typed setter, which is now also used directly from nsGlobalWindowOuter
to avoid problems that come with autodetecting unchanged dimensions,
when the current dimensions are outdated (e.g. immediately reverting a
change can be ignored).
Differential Revision: https://phabricator.services.mozilla.com/D160260
This is done using slightly different mechanisms for each of LoadInfo and
nsDocShellLoadState, and will be used in the next part to validate document
loads based on the RemoteType responsible for the load.
For subresource loads, the TriggeringRemoteType is fairly straightforward - it
is the process which created the channel. We can handle this by getting the
current remote type when creating the channel, and then using the remote type
of the sending process when receiving the LoadInfo over IPC to either replace
the triggering remote type, or validate it.
For document loads, the situation is a bit more complex, as there are at least
3 (potentially-)different processes responsible for different parts of the
navigation:
1. The "Triggering Process" is the process which provided the URI to load.
This is also the process which provides the Triggering Principal. This is
the process being tracked in this patch.
2. The "Loading Process" is the process which actually creates the channel and
starts the load. This may be the same as the triggering process, or may be
a different process starting the navigation on behalf of the triggering
process. In general this is the process hosting the current docshell,
though it may be the parent process in the case of parent-initiated loads.
3. The "Final Process" is the process which receives the response and renders
the final document. This isn't known at channel creation time, and is
determined by the result principal and process isolation policy.
This change uses a serializer and special field on nsDocShellLoadState to track
the "Triggering Process" for the load, even as the load state is serialized
between processes by tracking which loads were sent into which content
processes, and matching them up when the parent process sees them again. The
information is then copied into the LoadInfo before configuring the real
channel, so it can be used for security checks.
The "Triggering Process" is overridden to be the parent process for history
loads, as history loads are often started in processes which wouldn't normally
be able to navigate to those pages. This is OK thanks to the changes in part 1
which validate history loads against the real session history when SHIP is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D161198
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
The devtools test reloads a page twice in a row and depending on timing it isn't guaranteed that it leads to two requests anymore.
That test seems to fail on debug builds every now and then. The test itself expects 1 or more requests, but then assumes later that there
are at least 2.
Differential Revision: https://phabricator.services.mozilla.com/D160573
Following a suggestion from :mkmelin, this seems like an optimal solution: the overriding/duplication in m-c is removed, and all users get a more powerful default choice that they're still able to override with their own, should they so wish.
For clarity and to match other `about:` pages, the shared code is placed under `toolkit/content/`, and all content under `docshell/resources/` is removed.
Differential Revision: https://phabricator.services.mozilla.com/D156478
If we don't preserve the precursor principal in this case, we'll end up
doing an unnecessary process switch in some cases, which lead to a
test failure.
This patch also cleans up some logic around the first party origin
attribute with null principals, as the logic was only used in one place
and generally added some unnecessary complexity to NullPrincipal
itself.
Differential Revision: https://phabricator.services.mozilla.com/D155277
No test, since the patch is based on the crash reports. Creating a test which relies on some race conditions through IPC is hard.
Differential Revision: https://phabricator.services.mozilla.com/D154634
This should be a better fix. GeckoView assumes these don't change on .top
unless they are explicitly set.
I don't have an Android build environment handy, but I'll try to confirm.
Also, remove an unused flag while at it.
Differential Revision: https://phabricator.services.mozilla.com/D153107
When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
CookieJarSettings frequently gets populated in a place
where we have ready access to the Document/Channel it
is being constructed for. This lets us populate the boolean
and pass it into CookieJarSetting's constructor easily.
When it is created for LoadInfo, we need to plumb the URI
through by adding it to LoadInfo::CreateForDocument.
Differential Revision: https://phabricator.services.mozilla.com/D150588
When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
The current implementation of TimelineConsumers contains some unnecessary
complexity due to how it is initialized as a singleton, and the need for it to
be initialized and used in a threadsafe way. This patch attempts to simplify it
by making all members static, and removing the need to explicitly observe
shutdown for cleanup.
In addition, this approach avoids the risk of the type being accessed from
off-main-thread during initialization or shutdown.
Depends on D150442
Differential Revision: https://phabricator.services.mozilla.com/D150443
The main goal here is to get the wireframe test to work with
parent-controlled navigation.
This means we don't need to collect the wireframe any more in
PersistLayoutHistoryState, I think, because it is redundant.
I think we need to clear the wireframe in finish restore for
when we navigate back.
As a result of these changes, the two todo subtests in the
wireframe test now pass.
Differential Revision: https://phabricator.services.mozilla.com/D146252
When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
