`nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` is currently only used by HTTPS-First. It is used for fixing upgrade-downgrade loops and when loading history entries, as when we already know if HTTPS-First succeeded there or not, we have no need for trying to upgrade again and can disable HTTPS-First. With the changes introduced by Bug 1839612, `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` also applies to HTTPS-Only, which is a problem because disabling HTTPS-Only for history entries will result in them potentially being loaded insecurely without the user setting an exception. As a solution this patch just applies `nsILoadInfo::HTTPS_ONLY_EXEMPT_NEXT_LOAD`, the flag being set when `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` is set, when HTTPS-First is enabled, and renames both flags to reflect that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D185829
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
Test by Gijs. Note that I removed the .isActive assertion, because this doesn't
affect activeness.
We could make that change too, but that's a bigger change, and I think we want
to do this regardless.
The CAN_RUN_SCRIPT annotations are obsolete (they come from bug 1582042
which directly fired docshell activity events, but that's not true
anymore, bug 1635914 changed the setup a bit later).
Differential Revision: https://phabricator.services.mozilla.com/D185643
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
Test by Gijs. Note that I removed the .isActive assertion, because this doesn't
affect activeness.
We could make that change too, but that's a bigger change, and I think we want
to do this regardless.
The CAN_RUN_SCRIPT annotations are obsolete (they come from bug 1582042
which directly fired docshell activity events, but that's not true
anymore, bug 1635914 changed the setup a bit later).
Differential Revision: https://phabricator.services.mozilla.com/D185643
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
Calling `UpdateDefaultPreventedOnContent` separately from
`PreventDefault()` is error-prone. This patch should make it
safer.
Differential Revision: https://phabricator.services.mozilla.com/D186052
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
In the Storage Access API's latest draft, a few items were added to the user-agent state. Relevant here,
the source snapshot params gained two fields that are initialized from the sourceDocument during
snapshotting source params while navigating: "has storage access" and "environment id".
https://privacycg.github.io/storage-access/#ua-state
These are used to identify self-initiated navigations that come from documents that have obtained storage access.
Combined with a same-origin check, this determines if the destination document of the navigation should start
with storage access.
This is stricter than the current behavior, where if the permission is available, all documents start with storage access.
Instead, now a document will only have storage access if it requests it explicitly or if a same-origin document that has
storage access navigates itself to that document. This is seen as a security win.
Security discussion of this change was here: https://github.com/privacycg/storage-access/issues/113
Artur at Google wrote up a great summary here: https://docs.google.com/document/d/1AsrETl-7XvnZNbG81Zy9BcZfKbqACQYBSrjM3VsIpjY/edit#
Differential Revision: https://phabricator.services.mozilla.com/D184821
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
In the Storage Access API's latest draft, a few items were added to the user-agent state. Relevant here,
the source snapshot params gained two fields that are initialized from the sourceDocument during
snapshotting source params while navigating: "has storage access" and "environment id".
https://privacycg.github.io/storage-access/#ua-state
These are used to identify self-initiated navigations that come from documents that have obtained storage access.
Combined with a same-origin check, this determines if the destination document of the navigation should start
with storage access.
This is stricter than the current behavior, where if the permission is available, all documents start with storage access.
Instead, now a document will only have storage access if it requests it explicitly or if a same-origin document that has
storage access navigates itself to that document. This is seen as a security win.
Security discussion of this change was here: https://github.com/privacycg/storage-access/issues/113
Artur at Google wrote up a great summary here: https://docs.google.com/document/d/1AsrETl-7XvnZNbG81Zy9BcZfKbqACQYBSrjM3VsIpjY/edit#
Differential Revision: https://phabricator.services.mozilla.com/D184821
Test by Gijs. Note that I removed the .isActive assertion, because this doesn't
affect activeness.
We could make that change too, but that's a bigger change, and I think we want
to do this regardless.
The CAN_RUN_SCRIPT annotations are obsolete (they come from bug 1582042
which directly fired docshell activity events, but that's not true
anymore, bug 1635914 changed the setup a bit later).
Differential Revision: https://phabricator.services.mozilla.com/D185643
As otherwise it can race with the front-end setting the right zoom.
This is a bit sketchy, I'm open to other potential solutions?
But we don't have access to per-site zoom prefs in Gecko, so...
Depends on D184922
Differential Revision: https://phabricator.services.mozilla.com/D184923
The CanonicalBrowsingContext::IsPrivateBrowsingActive() function allows
us to know if private browsing is active. We need it to prevent setting
cookies if there is no active private browsing session.
Differential Revision: https://phabricator.services.mozilla.com/D184010
Nobody uses it and currently not super useful as the possible return value is limited to primitives. It could be extended to support DOM objects, but I don't know there's actual use cases for that as in many cases the promise is resolved with non-DOM values.
Differential Revision: https://phabricator.services.mozilla.com/D183026
- Also clear HTTPS_ONLY_EXEMPT for HTTPS-First in TestSitePermissionAndPotentiallyAddExemption
- Remove PotentiallyClearExemptFlag as we are now clearing the exemption every time
- Introduce new flag HTTPS_ONLY_EXEMPT_NEXT_LOAD which will set the exemption again after it being (potentially) cleared
- Set that flag when nsDocShellLoadState::IsExemptFromHTTPSOnlyMode is set, since that happens before the exemption is cleared
Differential Revision: https://phabricator.services.mozilla.com/D182322
The EditorEventListener for HTMLEditor is registered on document,
which is problematic because it can't receive events when the focus is
switched between elements in the same shadow tree due to shadow dom
encapsulation.
We fix this by moving the EditorEventListener to nsWindowRoot so the
events can always be received.
Differential Revision: https://phabricator.services.mozilla.com/D178215
The goal of this change is to detect content-initiated file URI loads
earlier such that crash stacks give us a better idea of what is
responsible for starting these loads.
These assertions explicitly only fire for system-principal triggered
loads of file URIs, as those should never be happening from within a web
content process.
Differential Revision: https://phabricator.services.mozilla.com/D182223
This involved moving ApplyCache from the .h into the .cpp because now that the class is no longer a template, forward declaration of DocAccessibleParent is not sufficient.
Differential Revision: https://phabricator.services.mozilla.com/D181852
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
Text passed to `IPCResult::Fail` (and, therefore, text passed to
`IPC_FAIL`) may end up in telemetry.
To avoid accidentally capturing unwanted information, restrict all such
text to compile-time constant strings, unless approved by data-review.
Differential Revision: https://phabricator.services.mozilla.com/D180152
The EditorEventListener for HTMLEditor is registered on document,
which is problematic because it can't receive events when the focus is
switched between elements in the same shadow tree due to shadow dom
encapsulation.
We fix this by moving the EditorEventListener to nsWindowRoot so the
events can always be received.
Differential Revision: https://phabricator.services.mozilla.com/D178215
This patch refactors the SearchService private initialized variables and how
the SearchService stores its initialization status. These changes capture whether
the SearchService has succeeded, failed or hasn't finished initialization yet.
There are also changes made to UrlbarSearchUtils on handling when SearchService
has failed to initialize or when it hasn't finished initializing yet and we wait.
In the case where the SearchService has failed on initialization, We allow
the code to continue so that it can reach UrlbarProviderPlaces. Once we
are able to reach UrlbarProviderPlaces, we can make database calls for the user's
history and bookmarks. This allows the user to interact with the addressbar and
search their history and bookmarks even if SearchService has failed to initialize.
Differential Revision: https://phabricator.services.mozilla.com/D176936
The EditorEventListener for HTMLEditor is registered on document,
which is problematic because it can't receive events when the focus is
switched between elements in the same shadow tree due to shadow dom
encapsulation.
We fix this by moving the EditorEventListener to nsWindowRoot so the
events can always be received.
Differential Revision: https://phabricator.services.mozilla.com/D178215
The EditorEventListener for HTMLEditor is registered on document,
which is problematic because it can't receive events when the focus is
switched between elements in the same shadow tree due to shadow dom
encapsulation.
We fix this by moving the EditorEventListener to nsWindowRoot so the
events can always be received.
Differential Revision: https://phabricator.services.mozilla.com/D178215
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
When the user clicks continue this time in the DoH fallback warning page
we want to set the defaultLoadFlags to LOAD_TRR_DISABLED_MODE so all of
the pages & subresources in the tab will not use TRR from that point
forward.
Setting it directly on docshell.defaultLoadFlags seems to not have the correct
behaviour when the page is using the Cross-Origin-Opener-Policy header,
as that causes the DocumentChannel to do a cross process redirect and
recreate the browsing context.
Setting the defaultLoadFlags on the browsingContext directly and
adding the field to `CanonicalBrowsingContext::ReplacedBy` seems to lead to
the expected behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D176959
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
To avoid unnecessary cloning of nsIInputStream, add a hasPostData
boolean attribute to tell whether a nsISHEntry has populated postData.
Differential Revision: https://phabricator.services.mozilla.com/D173237
To avoid unnecessary cloning of nsIInputStream, add a hasPostData
boolean attribute to tell whether a nsISHEntry has populated postData.
Differential Revision: https://phabricator.services.mozilla.com/D173237
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 combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
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 combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
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
nsIWebProgressListener is stored as a weak reference in
nsIWebProgress. To not have it garbage collected we need to keep a
reference to it.
Differential Revision: https://phabricator.services.mozilla.com/D171228
Some of the tests that fail (or only succeed) with SHIP are currently marked for
Fission. This makes them fail once we turn on SHIP without Fission.
Differential Revision: https://phabricator.services.mozilla.com/D169824
This is in order to make nsPresContext::UseOverlayScrollbars() thread-safe for
stylo usage.
Document::GetBrowsingContext() does ref-counting of main-thread-only
objects, and we don't want that.
Similarly nsPresContext::Theme() mutates the pres context which is not
something we can do from multiple threads.
Reviewed in: https://phabricator.services.mozilla.com/D168148
For that we need to:
* Make GetDPIRatioForScrollbarPart thread-safe: This was using the
widget for bug 1727289, but just looking at the print preview scale
is enough to fix that.
* Make nsPresContext::UseOverlayScrollbars() thread-safe: We store the
RDM pane stuff in the pres context.
The rest is pretty straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D168148
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
I can see that after navigation, allowJavascript is correctly set for the browsing context, but it seems we need to call
RecomputeCanExecuteScripts() to force it to be applied to the new page. Not sure if doing this here makes sense or if it should be done earlier.
Also there are still other issues with this feature:
- closing the toolbox does not reload the page: meaning JavaScript remains disabled on the page
- similarly all pages which have been put in bfcache will retain the javascript disabled/enabled setting
For the first issue, I wonder if we should force a reload when closing the toolbox (iff javascript disabled was toggled).
And for the second issue, could we invalidate contexts put in bfcache for a given browsing context when we toggle allowJavaScript?
Olli: Does this change make sense at least to fix the basic issue?
Differential Revision: https://phabricator.services.mozilla.com/D169182
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
This page is hidden behind a pref, but not behind an ifdef. I chose to
do this in order to simplify the potential release of this feature. I
don't foresee issues with bloating the binary during the development,
so this doesn't feel like a risk to me.
Differential Revision: https://phabricator.services.mozilla.com/D164613
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
This is possible in test situations, as a content document with a system
principal can call methods like window.open on a chrome document, which has a
different BCG. Treat these cross-group calls like they're coming from the
target document.
Differential Revision: https://phabricator.services.mozilla.com/D166120
Because the parent process lacks information about the current shell
size, the child has to send both the current and the new shell size to
the parent. The parent then applies the delta to the window size. This
can produce different results for calls with the same arguments,
whenever a previous call did not have enough time to update the child
with its new size.
The implementation is replaced by applying the delta in the child.
Differential Revision: https://phabricator.services.mozilla.com/D160261
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
The getter used to return CSS pixels, while the setter expected layout
device pixels. The nsIDocShellTreeOwner documentation used to suggest that
CSS pixels are used for getters and setters of the primary content and
the root shell size. Only the getter for the primary content size
happend to match that documentation.
Differential Revision: https://phabricator.services.mozilla.com/D161944
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Because the parent process lacks information about the current shell
size, the child has to send both the current and the new shell size to
the parent. The parent then applies the delta to the window size. This
can produce different results for calls with the same arguments,
whenever a previous call did not have enough time to update the child
with its new size.
The implementation is replaced by applying the delta in the child.
Differential Revision: https://phabricator.services.mozilla.com/D160261
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
The getter used to return CSS pixels, while the setter expected layout
device pixels. The nsIDocShellTreeOwner documentation used to suggest that
CSS pixels are used for getters and setters of the primary content and
the root shell size. Only the getter for the primary content size
happend to match that documentation.
Differential Revision: https://phabricator.services.mozilla.com/D161944
This adds a new set of options to static components.conf files to allow
specifying the protocol flags and default ports of a protocol handler, and
generates a separate table just for this purpose.
This will be used in the next part as part of replacing the existing protocol
handler lookup infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D162803
Splitting the test wasn't enough to prevent the frequent timeouts, and there really isn't a sensible way to split it any further.
Differential Revision: https://phabricator.services.mozilla.com/D163502
Because the parent process lacks information about the current shell
size, the child has to send both the current and the new shell size to
the parent. The parent then applies the delta to the window size. This
can produce different results for calls with the same arguments,
whenever a previous call did not have enough time to update the child
with its new size.
The implementation is replaced by applying the delta in the child.
Differential Revision: https://phabricator.services.mozilla.com/D160261
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
The getter used to return CSS pixels, while the setter expected layout
device pixels. The nsIDocShellTreeOwner documentation used to suggest that
CSS pixels are used for getters and setters of the primary content and
the root shell size. Only the getter for the primary content size
happend to match that documentation.
Differential Revision: https://phabricator.services.mozilla.com/D161944
This adds a new set of options to static components.conf files to allow
specifying the protocol flags and default ports of a protocol handler, and
generates a separate table just for this purpose.
This will be used in the next part as part of replacing the existing protocol
handler lookup infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D162803
Propagate the ability to pass triggeringRemoteType through the desktop frontend
in various places, such that it is set when using the context menu or content
click handler.
Differential Revision: https://phabricator.services.mozilla.com/D161834
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
With SHIP, we have a copy of the actual SessionHistoryEntry which is
responsible for a history load locally within the parent process. Using this,
we can validate any session history loads coming from the content process to
ensure that they correspond to actual outstanding history loads.
We can't do this for non-SHIP loads, as session history exists only within the
content process.
Differential Revision: https://phabricator.services.mozilla.com/D161197
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
Instead of imposing the min-width as a max-size, make prefwidth act as
it should (as suggesting a preferred width, but with min-content as a
minimum).
This can be reproduced locally by applying a patch like:
```
diff --git a/toolkit/profile/content/profileSelection.xhtml b/toolkit/profile/content/profileSelection.xhtml
index 3dd1c864f79f1..7e8cbf8ce8c3e 100644
--- a/toolkit/profile/content/profileSelection.xhtml
+++ b/toolkit/profile/content/profileSelection.xhtml
@@ -17,7 +17,7 @@
data-l10n-id="profile-selection-window"
orient="vertical"
prefwidth="min-width"
- style="min-width: 30em;"
+ style="min-width: 10em;"
onload="startup();">
<dialog id="profileWindow"
buttons="accept,cancel"
```
Before patch, stuff overflowed. This patch guarantees that everything is
on-screen.
Differential Revision: https://phabricator.services.mozilla.com/D161229
Instead of imposing the min-width as a max-size, make prefwidth act as
it should (as suggesting a preferred width, but with min-content as a
minimum).
This can be reproduced locally by applying a patch like:
```
diff --git a/toolkit/profile/content/profileSelection.xhtml b/toolkit/profile/content/profileSelection.xhtml
index 3dd1c864f79f1..7e8cbf8ce8c3e 100644
--- a/toolkit/profile/content/profileSelection.xhtml
+++ b/toolkit/profile/content/profileSelection.xhtml
@@ -17,7 +17,7 @@
data-l10n-id="profile-selection-window"
orient="vertical"
prefwidth="min-width"
- style="min-width: 30em;"
+ style="min-width: 10em;"
onload="startup();">
<dialog id="profileWindow"
buttons="accept,cancel"
```
Before patch, stuff overflowed. This patch guarantees that everything is
on-screen.
Differential Revision: https://phabricator.services.mozilla.com/D161229
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
DONTBUILD because this is just whitespace cleanup.
I found the files to fix up here using this command:
grep -r ' ' * 2>/dev/null | grep -v "other-licenses" | grep "idl:"
I replaced the tab characters with however many spaces seemed consistent with
the indentation in the surrounding code (and did some minor space-indentation
cleanup in contextual lines to preserve alignment, in a few cases).
Differential Revision: https://phabricator.services.mozilla.com/D160577
This splits the parent-triggered and child-triggered unload attempts into
separate tests. I could also split the tests for each subframe level into
separate tests, but let's see how this does for now.
Differential Revision: https://phabricator.services.mozilla.com/D159228
I modified the boolean associated with fixupCreateAlternateURI to only
be true if the host which contains the prefix and suffix differs from
the fixed up version. This will allow the boolean to be false in cases
where the fixup doesn't change the host. Then for the DNS error page,
there is a check as to whether the host or protocol was changed.
Differential Revision: https://phabricator.services.mozilla.com/D159175
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
As per spec, see https://drafts.csswg.org/css-color-adjust/#color-scheme-effect:
> In order to preserve expected color contrasts, in the case of embedded
> documents typically rendered over a transparent canvas (such as
> provided via an HTML iframe element), if the used color scheme of the
> element and the used color scheme of the embedded document’s root
> element do not match, then the UA must use an opaque canvas of the
> Canvas color appropriate to the embedded document’s used color scheme
> instead of a transparent canvas.
After bug 1782596 we were using the preferred rather than used
color-scheme, which is the right thing to do for prefers-color-scheme,
but not for the canvas background.
Differential Revision: https://phabricator.services.mozilla.com/D155831
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117
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
Marco Bonardo
Sandor Molnar
Mathew Hodson
Tom Marble
Cosmin Sabou
Malte Juergens
Daisuke Akatsuka
Andrew McCreight
Stanca Serban
Vinny Diehl
owlishDeveloper
Gregory Pappas
Sean Feng
Emilio Cobos Álvarez
Iulian Moraru
Markus Stange
Cristian Tuns
Narcis Beleuzu
Benjamin VanderSloot
Natalia Csoregi
Olli Pettay
Peter Van der Beken
Tim Huang
Tooru Fujisawa
Paul Zuehlcke
Cristina Horotan
Kagami Sascha Rosylight
Mark Banner
Zac McKenney
CanadaHonk
Greg Tatum
Nika Layzell
Kershaw Chang
Norisz Fay
James Teh
Noemi Erli
Ray Kraesig
Florian Quèze
Neil Deakin
mcheang
Kris Maglione
Gijs Kruitbosch
Daniel Holbert
Masayuki Nakano
Valentin Gosu
Butkovits Atila
Dana Keeler
Alexandre Lissy
Tom Schuster
Emily McDonough
serge-sans-paille
Rob Wu
Andreas Farre
Andi-Bogdan Postelnicu
lyavor
Saira Abdulla
Makoto Kato
Marian-Vasile Laza
Jens Stutte
Brad Werth
Julian Descottes
Joel Maher
Nazım Can Altınova
Adam Vandolder
Edgar Chen
Artur Iunusov
Sylvestre Ledru
Matthias Camenzind
Tom Schuster
Manuel Bucher
Martin Robinson
Kris Maglione
Greg Stoll
Simon Friedberger
Paul Adenot
James Teow
Eemeli Aro
Mike Conley
Pier Angelo Vendrame
Sebastian Hengst
Andreea Pavel
Christian Holler