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
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
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
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
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
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
As a temporary fix to prevent crashes we are loosening the `CanSet`
restrictions for TouchEventsOverrideInternal. In the future this will
be fixed properly by changing DevTools to set this property from the
parent only, at which time tighter restrictions on setting
`TouchEventsOverrideInternal` may be added.
Differential Revision: https://phabricator.services.mozilla.com/D103080
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Syncing the container FeaturePolicy across BrowsingContext is actually
a bit more heavy-handed than necessary. We only ever need a container
FeaturePolicy when inheriting a FeaturePolicy in exactly the document
the container contains. Not every process that the tree the container
is a part of. So instead of storing a FeaturePolicy in a synced field,
we manually send it to the correct WindowGlobalChild (which
corresponds to a document) and retrieve it from there.
Differential Revision: https://phabricator.services.mozilla.com/D61479
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
This should prevent content process crashes when there are
cross-origin descendants with an override set.
There is a slight change in behaviour when an override is set after
a descendant context has previously set one. This shouldn't be a
problem since devtools only wants to expose touch simulation at the
tab level. Additionally this new behaviour is reasonable and would
allow devtools to implement the same semantics by doing the clearing
themselves (if needed).
Differential Revision: https://phabricator.services.mozilla.com/D97797
A new `BrowsingContext` field has been added to track the active
browser window for the `:-moz-window-inactive` pseudoclass. This
field takes the place of `nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
A new `BrowsingContext` field has been added to track the active
browser window for the `:-moz-window-inactive` pseudoclass. This
field takes the place of `nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
This change removes docshell's `mTouchEventsOverride` and replaces it
with a new `BrowsingContext` field `TouchEventsOverrideInternal`.
All uses of the old field have been replaced and an override should
now work under fission when there are cross-origin descendent frames.
Differential Revision: https://phabricator.services.mozilla.com/D96414
