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
