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