This patch adds a new measurement to the histogram about the elapsed time
of `ShellExecuteByExplorer`. If ShellExecuteByExplorer takes long in
a considerable number of instances, we need to consider fixing bug 1646986.
Differential Revision: https://phabricator.services.mozilla.com/D84407
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
The aim of the code we're modifying here is to block things in one browsingcontext
tree from opening external links in another browsingcontext tree (and causing the
external protocol dialog to show up for that tab/window) -- except if the other
browsingcontext into which something is being loaded is same-origin.
Unfortunately the pre-patch code assumed that it would find currentWindowGlobal
objects for each browsingcontext, and it turns out that's not guaranteed,
especially in the case of hidden iframes, which turn out to be quite commonly
used for external protocol launches.
This patch fixes this by continuing to move towards the root of the browsingcontext
tree even if there's no currentWindowGlobal (though logically speaking, this
should only be necessary for the first iteration of the loop, it seems easier to
just always check this). It also adds a test for this behaviour working.
Differential Revision: https://phabricator.services.mozilla.com/D83015
The aim of the code we're modifying here is to block things in one browsingcontext
tree from opening external links in another browsingcontext tree (and causing the
external protocol dialog to show up for that tab/window) -- except if the other
browsingcontext into which something is being loaded is same-origin.
Unfortunately the pre-patch code assumed that it would find currentWindowGlobal
objects for each browsingcontext, and it turns out that's not guaranteed,
especially in the case of hidden iframes, which turn out to be quite commonly
used for external protocol launches.
This patch fixes this by continuing to move towards the root of the browsingcontext
tree even if there's no currentWindowGlobal (though logically speaking, this
should only be necessary for the first iteration of the loop, it seems easier to
just always check this). It also adds a test for this behaviour working.
Differential Revision: https://phabricator.services.mozilla.com/D83015
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
The WPT a-download-click-404.html requires this behaviour for links with the download attribute, and this is also the current behaviour for Content-Disposition: Attachment (see bug 1604308).
This previously worked because the parent process version of nsDocumentOpenInfo failed (with NS_ERROR_FILE_NOT_FOUND), but the error code was discarded and we forwarded the channel to the content process. The content process version then would then return NS_ERROR_WONT_HANDLE_CONTENT since the load requires downloading, but we don't allow that in the content process. This new error code is one that doesn't have an associated error page (unlilke the original error), so was silently discarded.
Differential Revision: https://phabricator.services.mozilla.com/D81014
When we hit the stylesheet cache for an existing stylesheet in a
different document:
* There's no existing preload in the PreloadService (because the sheet
was loaded in another document).
* We don't create a PreloaderBase (because we don't trigger a load at
all).
* And thus we believe the load has just errored, which is wrong...
Fix it by properly passing through the "already complete" status from
PreloadStyle.
Note that there's still another issue, which is that we'd still hit this
broken path if two stylesheets with the same URI are loading in
different documents and the CSS loader coalesces them.
For that, I think we'd have to make SheetLoadData the thing that
actually implements PreloaderBase. This is kind of an obscure case, and
SheetLoadData has a pretty complex lifetime already (keeps alive a whole
lot of stuff), so I'd prefer to do this in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D80289
We probably should remove the referrer policy check altogether in
bug 1642591, but the preload code still uses the whole referrer as the
key for css, which the css loader stopped doing in bug 1599160.
So this should be an uncontroversial simplification.
Differential Revision: https://phabricator.services.mozilla.com/D79810
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
Toshihito Kikuchi
Emilio Cobos Álvarez
Gijs Kruitbosch
Cameron McCormack
Marco Bonardo
Cosmin Sabou
Simon Giesecke
Frederik Braun
Kris Maglione
Nika Layzell
Mihai Alexandru Michis
Sebastian Streich
Narcis Beleuzu
Butkovits Atila
Matt Woodrow
Razvan Maries
Dorel Luca
Honza Bambas
Noemi Erli
Marco Castelluccio