Before this patch we would add the shutdown blockers in `ContentParent::Init`. This had two downsides:
1. The blockers were added each time we recycled an existing process again.
2. The time period between creating a new process and using it was not covered by shutdown blockers at all.
This patch anticipates the addition of the shutdown blockers to the very beginning of `ContentParent`'s lifetime, ensuring that it happens only once and that they will be removed also in case of process creation failures.
Shutdown blockers are now only added inside `BeginSubprocessLaunch` and removed in `LaunchSubprocessReject`, `ActorDestroy` or `KillHard` - that is at the very beginning and the very end of the process' life.
Differential Revision: https://phabricator.services.mozilla.com/D143711
In Bug 1761233, some crashes happened with "called Option::unwrap() on a None value". But it is not clear yet where crash happened. It is helpful to make clear where the crash happened.
Differential Revision: https://phabricator.services.mozilla.com/D144255
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
Now that we send everything (except sometimes the user value
is sanitized) we should no longer perform this check.
This is also good because it eliminates security code you
have to have (and thus accidently omitting it is a
vulnerability) and changes it to security code that happens
automatically, and is enforced by the compiler (via mandatory
ctor argument.)
Depends on D141414
Differential Revision: https://phabricator.services.mozilla.com/D141415
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
These tests are failing intermittently as, I think, the label gets localized
asynchronously.
So instead of checking the computed translated string, we only check that the
attribute for the item name is properly set.
Differential Revision: https://phabricator.services.mozilla.com/D144163
I tried various approaches around the session restore, but this isn't reliable.
Using an environment variable is much easier and also help making the path global
for the whole instance in case we close and reopen it.
Differential Revision: https://phabricator.services.mozilla.com/D143695
Automatic update from web-platform-tests
Throw exception based on exclusions when creating sanitized cookies
When we get a nullptr cookie from ToCanonicalCookie we assume that
there is an exception to explain the failure. We have a DCHECK to
verify such scenario. However, we only generate assertions if there is
any problem with the cookie url.
The CreateSanitizedCookie function, called to generate the return value
with the canonical cookie, performs some additional checks before
parsing the cookie string. Any error is described in as exclusion in
the CookieInclusionStatus instance. If the status has any exclusion, a
nullptr cookie is returned, but no exception is generated.
The bug 1315053 describes a scenario where we get a nullotr cookie
without an exception, violating the previously mentioned DCHECK. This
change fixes the bug by generating exceptions based on the exclusions
comment if the CreateSanitizedCookie adds any on the status instance.
This change makes our implementation spec complaint, according to what
is stated in the CookieStore-set method [1] algorithm:
"2- If r is failure, then reject p with a TypeError and abort these steps."
[1] https://wicg.github.io/cookie-store/#CookieStore-set
Bug: 1315053
Change-Id: I0ebbf727f7404391b12446a457247c4468754015
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3582579
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Cr-Commit-Position: refs/heads/main@{#992339}
--
wpt-commits: 4e9035fad8bcac85717069a50ab8be5e69a5cadd
wpt-pr: 33622
Automatic update from web-platform-tests
Consolidate header files for client hint WPTs
Move files with the same "Accept-CH" header to their own directory,
remove "Accept-CH" line from header file, and add "__dir__.headers" file
This will make it easier to update header files for added hints in later
CLs
No values were changed, only moved
Bug: 1304740
Change-Id: I065eb85ab8f10a79161366fa491b1f30a22a097e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3542073
Reviewed-by: Ali Beyad <abeyad@chromium.org>
Commit-Queue: Victor Tan <victortan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#992261}
--
wpt-commits: 89d5523c9ef343688f4a83a63a22e84ebc010544
wpt-pr: 33349
Automatic update from web-platform-tests
idle-detection: Reject start Promise on abort
This change fixes the IdleDetector interface's start() method so that if
the provided AbortSignal is signaled before the Promise it returns
settles it will reject with the provided abort reason instead.
In addition to violating the specification this scenario created an
internal consistenty error which triggered a DCHECK in Update() but was
otherwise harmless. This issue was introduced by the original change
that moved IdleDetector to use an AbortSignal and made it so that the
`resolver_` field was never actually populated with the Promise returned
by start().
Tests have been added to more completely exercise the AbortSignal
behavior.
Bug: 1315755
Change-Id: I394587bddf2e8176ff3f691d7f33e494af364684
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3582549
Auto-Submit: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Matt Reynolds <mattreynolds@chromium.org>
Commit-Queue: Matt Reynolds <mattreynolds@chromium.org>
Cr-Commit-Position: refs/heads/main@{#992258}
--
wpt-commits: ecf7b95fb7122554c6a226584e0b18e7ad0e865b
wpt-pr: 33620
Automatic update from web-platform-tests
Make CloseWatcher process escape key after default event handlers
Before this patch, CloseWatcher processes the escape key before default
event handlers, which means that it takes precedence over all default
behavior of elements in the page when the escape key is pressed, such as
pressing escape on <input type=search>.
This patch adds some plumbing to make CloseWatcher get the escape key
event after <input type=search> does and check for defaults already
being handled.
Fixed: 1312594
Change-Id: I156e329c7c7ea0c8742c102b87c221d9ce10f4ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3570026
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#992226}
--
wpt-commits: 45d050aaa685ac540ffca065e2f64d7b21c89558
wpt-pr: 33587
Automatic update from web-platform-tests
Add a feature to deprecate <param> URL inside <object>
This sets up a flag, default enabled, which will allow us to slowly
disable this feature via Finch and monitor for web compat issues.
With this CL, there should be no behavior change, since the flag
is enabled by default.
I2D:
https://groups.google.com/a/chromium.org/g/blink-dev/c/dDu4CgAwRwQ/m/--LdmX3vEwAJ
Bug: 1315717
Change-Id: I94b2ffcc21d61d0a59bcd2353235cf28d4b93fad
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3580635
Commit-Queue: Mason Freed <masonf@chromium.org>
Commit-Queue: Domenic Denicola <domenic@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: Domenic Denicola <domenic@chromium.org>
Cr-Commit-Position: refs/heads/main@{#992186}
--
wpt-commits: d9c02dd6115aabf70eb339e25a7ad27fa57e5215
wpt-pr: 33624
Automatic update from web-platform-tests
webauthn: add remoteDesktopClientOverride extension IDL
This adds the IDL definition for a WebAuthn client extension that lets
a trusted remote desktop client web app execute a WebAuthn API request
that has been forwarded from a remote host, on behalf of the origin that
made the original remote request.
Availability of the extension is gated on a Blink Runtime flag which is
initialized from a command-line switch. The switch in turn can be set
via an internal-only enterprise policy,
WebAuthenticationRemoteProxiedRequestsAllowed.
(The same enterprise policy will also allow the extension to be used by
a single origin belonging to a Google-internal version of Chrome Remote
Desktop, for initial experimentation with this feature. But this CL only
adds the extension IDL definition and plumbs it through the mojo
interface. It isn't actually wiring up any of that behavior yet.)
Feature explainer: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Remote-Desktop-Support
Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/3EFGXppjkWo
Bug: 1314480
Change-Id: I91225175232c8027c17ffa2ef4b0d5c110f9ba5e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3499163
Reviewed-by: Adam Langley <agl@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Cr-Commit-Position: refs/heads/main@{#992107}
--
wpt-commits: 8d7ca2fc953c421ff8acd3cc64ea656da5bac9bd
wpt-pr: 33597
Automatic update from web-platform-tests
Bubble scrollIntoView from position:fixed in frame
LayoutBox::ScrollRectToVisibleRecursive was erroneously stopping the
recursion once it reached a position:fixed element, assuming that
further recursion to the parent was unnecessary. This is true for the
main frame; however, in an iframe, the element is only fixed to its
frame's scroll offset. Ancestor scrollers of the frame can still affect
the target element's position so scrolling should continue with them.
The behavior is that once a position:fixed element is reached, the
recursion should continue from its frame's parent.
This CL also takes the opportunity to clean up the
ScrollRectToVisibleRecursive method to make the logic clearer and
iterative rather than recursive. The LayoutBox version of
ScrollRectToVisible is now solely to walk up as high as it can in the
layout tree of the local frame root. Crossing IPC boundaries is
performed by LayoutObject. The only caller that doesn't go through
LayoutObject is Autoscroll but that latches to a single scroller and
doesn't bubble at all so isn't a concern.
See also: https://github.com/w3c/csswg-drafts/issues/5492
Bug: 1019427
Change-Id: I336866b927431c2faf2b645474dd32cd1771bb78
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3579486
Reviewed-by: Daniel Libby <dlibby@microsoft.com>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#992062}
--
wpt-commits: e3d1836de35ba784549c9ab98fef6de57646af55
wpt-pr: 33572
Automatic update from web-platform-tests
Update tests to match ARIA 1.2 global states and property list (#33523)
The following 4 attributes were removed from global attributes:
* aria-disabled
* aria-errormessage
* aria-haspopup
* aria-invalid
Tests of these attributes are now on elements which support each
role.
Co-authored-by: Valerie Young <spectranaut@igalia.com>
--
wpt-commits: b2aeec05d753c742ea35b4cc395d52b4b168245b
wpt-pr: 33523
Automatic update from web-platform-tests
Tests for requestIdleCallback deadline computation (#31177)
* Tests for requestIdleCallback deadline computation
Deadline should be:
- capped at 50ms
- capped at 1000/60 (~16ms) when there is a pending rAF callback
- capped at the time of the next timeout
- be updated when the above conditions change, during the callback itself
See https://github.com/whatwg/html/pull/7166
Co-authored-by: Philip Jägenstedt <philip@foolip.org>
--
wpt-commits: 6ae31b2052754cb7645ba0e4c7c8ec43681d4a36
wpt-pr: 31177
Tom Ritter
Nika Layzell
Alexandra Borovova
Andrew McCreight
Jens Stutte
Mike Kaply
Marco Bonardo
sotaro
Nicolas Chevobbe
Yury Delendik
Gabriele Svelto
Alexandre Poirot
Henrik Skupin
moz-wptsync-bot
Michael[tm] Smith
dependabot[bot]
Javier Fernández García-Boente
Joey Arhar
Victor Tan
Reilly Grant
Mason Freed
Martin Kreichgauer
David Bokan
Valerie Young
Noam Rosenthal