Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
With multiple windows, a browsing context being active doesn't guarantee
being in the active window, so we explicitly check for that. We need to
introduce an special case for the initial document because the initial
document in the active window requesting focus breaks focusing the
urlbar on a new window.
Differential Revision: https://phabricator.services.mozilla.com/D104326
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
That doesn't go through BrowsingContext::InternalLoad. This matches the
behavior of clicking links and the behavior of other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D103720
I'll simplify all the popup-blocking setup in a follow-up, but this is
the low-risk change.
Need to add a test for this of course. Kinda baffled we did not have
any.
Differential Revision: https://phabricator.services.mozilla.com/D103571
I'll simplify all the popup-blocking setup in a follow-up, but this is
the low-risk change.
Need to add a test for this of course. Kinda baffled we did not have
any.
Differential Revision: https://phabricator.services.mozilla.com/D103571
Take a step towards replacing the encoding menu with a single menu item that
triggers the autodetection manually. However, don't remove anything for now.
* Add an autodetect item.
* Add telemetry for autodetect used in session.
* Add telemetry for non-autodetect used in session.
* Restore and revise telemetry for how the encoding that is being overridden
was discovered.
Differential Revision: https://phabricator.services.mozilla.com/D81132
Storing the charset on cache entries makes the code path uselessly different
when loading from cache relative to uncached loads. Also, for future
telemetry purposes, caching the charset obscures its original source.
Differential Revision: https://phabricator.services.mozilla.com/D101570
In the case we click a link from inside the frame, we don't want to
check for activation from the parent window but ourselves.
It feels like using the sourceWindowContext for these checks is always
the right thing to do, but it's not always possible if we set the
location.href from an out-of-process parent. In this case, we fall back
to consuming user activation on the iframe itself. This is tested in
browbrowser_protocol_ask_dialog.js when run with fission enabled.
We could consider making the user activation stuff more
multiprocess-friendly, but it's not clear to me it's worth it for this
particular edge case.
Differential Revision: https://phabricator.services.mozilla.com/D100578
