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
Olli Pettay
Nika Layzell
Simon Giesecke
Mark Banner
Sonia Singla
Alexandru Michis
Noemi Erli
smolnar
Jan-Erik Rediger
Emilio Cobos Álvarez
Gijs Kruitbosch