Raise for the race-network-and-fetch-handler source without handler

This reflects the change in w3c/ServiceWorker#1719.
Instead of silently fallback to network, let me make `addRoutes()` raise
if the race-network-and-fetch-handler source is used without having a
fetch handler.

Fixed: 391990601
Change-Id: Ic944e183286cd056235b0fe272c543533dfaa86f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6211317
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Shunya Shishido <sisidovski@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Keita Suzuki <suzukikeita@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1412763}

[fetch-later] Fix incorrect quota behavior in same-origin iframes

This CL incorporate [recent spec changes][1] to solve various issue:
- Fix fetchLater requests made in same-origin iframes not respecting
  pending fetchLater requests from its parent and neighbor iframes.
- No longer perform complicated quota calculation in fetchLater
  algorithms to prevent from taking up [inflightKeepaliveBytes][2].
  This is left as an open spec question to solve in the future.

As a result, what this CL really changes:
- Update `GetAvailableDeferredQuota()` to take source frame instead of
  control frame, and update related implementation.
- Update DeferredLoader's `invoke_state_` to match current spec.

[1]: whatwg/fetch@139351f
[2]: https://fetch.spec.whatwg.org/#ref-for-request-keepalive-flag%E2%91%A1

NO_IFTTT=changes reflected in tools/metrics/histograms/metadata/blink/enums.xml

Bug: 40276121
Change-Id: Ie41ffdf7558860ff34901c547578ebf81189f3a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6193934
Reviewed-by: Adam Rice <ricea@chromium.org>
Commit-Queue: Ming-Ying Chung <mych@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1412755}

IDB WPTs: Extend idbcursor-direction related tests to workers

The update modifies idbcursor-direction related WPTs to run not
only in window environments but also on dedicated, service, and shared
workers.

Change-Id: I7bbb5a656eca9239a02644a96cdbb2b9540cccf2
Bug: 41455766
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6197324
Auto-Submit: Garima Chadha <garimachadha@microsoft.com>
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Reviewed-by: Rahul Singh <rahsin@microsoft.com>
Commit-Queue: Rahul Singh <rahsin@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1412726}

Revert "Ensure AbortSignal.throwIfAborted doesn't modify the message …

…of an abort error"

This reverts commit 0e0ef178e05e3f81b0de04c8f0197fe3ab608f41.

Reason for revert: Possible culprit for windows builder closure, see https://g-issues.chromium.org/issues/393009392.

Original change's description:
> Ensure AbortSignal.throwIfAborted doesn't modify the message of an abort error
>
> Fixed: 392413688
> Change-Id: I3639c573cd7349eac1f9b09c427a5a52bccdda72
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6209470
> Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
> Commit-Queue: Nate Chapin <japhet@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1412605}

Change-Id: Ifb785338a85e77e845a677940fc1353b74757b0f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6211537
Commit-Queue: Patti Lor <patricialor@chromium.org>
Owners-Override: Patti Lor <patricialor@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Patti Lor <patricialor@chromium.org>
Auto-Submit: Patti Lor <patricialor@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1412694}

Update background-image-table-cells-straddling-no-repeat.html (web-pl…

…atform-tests#50357)

This test currently fails in Safari while giving the right result, because of fuzzy issues. This add a fuzzy meta.

Add WPT to check for the default "list-style-position:outside" marker…

…-placement on bare li elements.

At time of writing, currently-released Chromium and WebKit versions have a bug
where they render bare "li" elements (those lacking a "ul" parent) using
"inside" marker-placement, even though they have the correct "outside" value in
the computed style. (Note that WebKit has fixed this in trunk/tech-preview.)

This patch has an automated testcase that fails if that bug is present. This
test checks that the marker is placed consistently in an "outside" position,
regardless of whether the li has a ul parent.  For good measure, this patch
also includes a notref/mismatch reference-case which explicitly uses the
"inside" marker-position that browsers with this bug use for the testcase.

Chrome 132 and Safari 18.2 release versions both fail this test; they render
the testcase in a way that *matches* the notref/mismatch case, and *does not
match* the reference case.  Firefox Nightly 136 and current Safari Tech Preview
fully pass the testcase.

Differential Revision: https://phabricator.services.mozilla.com/D235868

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1944384
gecko-commit: 41fa68489c9e8dfa78faf1328f40353b000ad5f1
gecko-reviewers: TYLin

Ensure AbortSignal.throwIfAborted doesn't modify the message of an ab…

…ort error

Fixed: 392413688
Change-Id: I3639c573cd7349eac1f9b09c427a5a52bccdda72
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6209470
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1412605}

Make `PresShell::EventHandler::DispatchEvent` retarget `mousemove` ev…

…ent if preceding boundary events removed the target

Chrome dispatches `mousemove` event on the preceding `mouseover` target even if
the target is removed from the DOM tree.  However, once the
"Boundary Event Dispatch Tracks Node Removal" feature is enabled, Chrome Canary
dispatches `mousemove` on the last deepest `mouseenter` event target which is
still connected.  Therefore, we should follow their new behavior if it's simply
possible.

Note that if `pointeover` target is removed, Chrome does not dispatch
`pointermove` on the last deepest `pointerenter` target. Therefore, this patch
limits the behavior change only for `eMouseMove`.

Differential Revision: https://phabricator.services.mozilla.com/D235807

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1944191
gecko-commit: be17ac5dd59b729070b263fe835815e86beea2b7
gecko-reviewers: smaug

Add test checking the lang attribute affects rendering (web-platform-…

…tests#50336)

[wdspec] add invalid tests for session.subscribe with user contexts (w…

…eb-platform-tests#50290)

* [wdspec] add invalid tests for session.subscribe with user contexts

* rename userContexts