This URI is intended to reflect the currentURI field on the content nsIDocShell,
and is the value used for getters like `window.location.href`. For most
documents, this generally matches the Document URI on WindowGlobalParent, it
does not match in specific cases such as error pages or when performing a
session restore.
The field is kept up-to-date by listening to `OnLocationChange` notifications
from the content process, and is ignored when the BrowsingContext is loaded in
the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D105559
The check in this function was added in bug 82236 to avoid an issue in the
mozilla suite where the UI would update to a subframe's URI. This came up
previously in bug 1206879 when we observed we weren't sending OnLocationChange
events when we were expecting, which was causing issues for pushState location
changes. A workaround was added in that bug to avoid the issue for the specific
case of pushState.
This patch removes the redundant check, and reverts the workaround added in that
bug. Unfortunately, we aren't able to fully remove nsISHEntry::GetIsSubframe, as
it is now used by Browser{Parent,Child}::CanCancelContentJS.
Differential Revision: https://phabricator.services.mozilla.com/D105555
The change to dom/base/nsFrameLoaderOwner.cpp is to log about the issues but still ensure we don't crash.
I'd prefer to not put error loads to bfcache.
Differential Revision: https://phabricator.services.mozilla.com/D107300
This automatically fixes issues for these rules: dot-notation, object-shorthand and mozilla/no-useless-parameters
The other enabled rules had no issues associated with them, so are enabled without code changes.
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D107424
We enable compilation of FOG/Glean on _all_ platforms.
We disable Glean initialization and metric recording on Android (GeckoView) by respecting MOZ_GLEAN_ANDROID.
This way GeckoView just works, consumers don't need to think about it (except in tests, these need to be disabled for Android builds).
Stubbing out the metric implementations will happen in the commits after
this one.
Differential Revision: https://phabricator.services.mozilla.com/D106766
The check was a bit too general it seems. Explicitly allow moving focus
for link clicks and window.open(), which are the things we have tests
for and care about moving focus.
Differential Revision: https://phabricator.services.mozilla.com/D107039
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
EvictOutOfRangeContentViewers call in SetFrameLoader doesn't do anything in this patch, but will
work with some followups.
Differential Revision: https://phabricator.services.mozilla.com/D105235
The name RemotenessChangeState uses same the convention as the related methods, even though there might
not be a remoteness change happening, only a browsing context switch. But the naming
inconsistency exists there even without any bfcache work.
RemotenessChangeState will be renamed to RemotenessChangeOptions in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D105229
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
EvictOutOfRangeContentViewers call in SetFrameLoader doesn't do anything in this patch, but will
work with some followups.
Differential Revision: https://phabricator.services.mozilla.com/D105235
The name RemotenessChangeState uses same the convention as the related methods, even though there might
not be a remoteness change happening, only a browsing context switch. But the naming
inconsistency exists there even without any bfcache work.
RemotenessChangeState will be renamed to RemotenessChangeOptions in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D105229
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
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
First, it should be called "Lookup" rather than "Get" because it returns
DataType (rather than UserDataType), but that would still be confusing,
since as opposed to other Lookup* methods, it does not return a DataType&
(and obviously, it can't). So "Extract" seems to be a better name, cf.
mozilla::Maybe::extract.
Differential Revision: https://phabricator.services.mozilla.com/D105471
In some cases, a content process may think they should be able to make a change
to a synced field, but in the meantime something in the parent process has
changed and the change can no longer be applied. This was the cause of a number
of issues around the in-flight process ID, and can cause issues such as crashes
if the CanSet method was made too strict.
This patch introduces a new possible return type from `CanSet` which allows
requesting a `Revert`. A reverted field change will either be cancelled at the
source (if the CanSet fails in the setting process), or will be cancelled by
sending a new transaction back to the source process reverting the change to
ensure consistency.
In addition, some additional logging is added which made it easier to locate the
underlying bug and verify the correctness of the change.
The current primary use-case for this new feature is the CurrentInnerWindowId
field which can be updated by the previous process' docshell after the parent
process has already performed a switch to a new process. This can lead to the
current WindowContext being inaccurate for a BrowsingContext in some edge cases
as we allow the flawed set due the in-flight process ID matching.
This patch changes the logic to no longer check the in-flight process ID, and
instead revert any changes to the CurrentInnerWindowId field coming from a
process which is not currently active in the BrowsingContext.
No tests were added as it is very timing-sensitive, and difficult to create the
specific scenario, however without these changes my patch for bug 1663757
consistently causes geckoview-junit crashes due to currentWindowGlobal being
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D105553
The serialization method for SessionHistoryInfo uses some low-level
functions to pack up some of the clone data, but this method
actually has a PContent actor available, so it can use one of the
nicer BuildClonedMessageDataFor methods to send this, which
should improve support for pushMessage with blobs.
The read method already uses the StealFromClonedMessageDataFor
methods so no changes are required there.
Differential Revision: https://phabricator.services.mozilla.com/D104775
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
When binding delegates blur() to BrowsingContext::Blur, the remote side skips
the check given that there is no js on the stack, but we should not skip the
check. This only affects design-mode which allows the focus moving to the root
element.
Differential Revision: https://phabricator.services.mozilla.com/D104008
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
When binding delegates blur() to BrowsingContext::Blur, the remote side skips
the check given that there is no js on the stack, but we should not skip the
check. This only affects design-mode which allows the focus moving to the root
element.
Differential Revision: https://phabricator.services.mozilla.com/D104008
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
- Moved aboutaddons.html at the root of the about:addons page
- renamed aboutaddons.js `initialize` global function to `initializeView` (and renamed `show` and `hide` global functions accordingly)
- Simplify initial load logic a bit more:
- remove gCategories
- moved responsability of the CategoriesBox initialization to the `initializationView` function
- replaced initialization logic based on `gPendingInitializations` and `notifyInitialized` with
a `promiseInitialized` global resolved when `initializeView` method has been called and its return value resolved
- Fix test helpers and test failures
- InlineOptionsBrowser: take into account that browser-custom-element does opt-in the delayedConnectedCallback behavior
and browser.loadURI may throw if called while the document is still loading.
Differential Revision: https://phabricator.services.mozilla.com/D96472
We keep mMedium in nsPresContext rather than just looking it up in the
browsing context because that's used quite more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D103782
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
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
Bogdan Tara
Mark Banner
Henri Sivonen
Olli Pettay
Nika Layzell
Simon Giesecke
Sonia Singla
Alexandru Michis
Noemi Erli
smolnar
Jan-Erik Rediger
Emilio Cobos Álvarez
Gijs Kruitbosch
Eitan Isaacson
Kris Maglione
Alexis Beingessner
Sean Feng
Anny Gakhokidze
Andrew McCreight
Edgar Chen
Andreea Pavel
Yura Zenevich
Kershaw Chang
Luca Greco
Brindusan Cristian