1. Use GetWithoutInvalidation() instead of Get() in DCHECKs.
We should never call Get() inside of a DCHECK(), because this can
lead to a different code path depending on whether DCHECKs are enabled.

2. Get() should not cause immediate side effects. At most, it should
queue up an invalidation for later processing.

Fixing #1 and #2 were required in order to get past a first set of
errors introduced by the new test.

3. The actual fix -- avoid infinite loop by calling a special
new SlotAssignmentWillChange(), rather than ChildrenChanged(),
where a minimal GetWithoutInvalidation() is called that does not
lead to IsShadowContentRelevantForAccessibility() => FirstChild() =>
RecalcAssignedNodes() => ChildrenChanged() ... (infinite loop).

A simpler potential fix is in CL:2965317 but requires more
research. It's also mentioned in a TODO comment.

Bug: 1219311
Change-Id: Iafaa289f241a851404ce352715d2970172a2e5f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2961158
Reviewed-by: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Reviewed-by: Dominic Mazzoni <[email protected]>
Commit-Queue: Aaron Leventhal <[email protected]>
Cr-Commit-Position: refs/heads/master@{#892778}

In the case that a popover contains an invoker that points back to that
invoker, the tab navigation code used to get confused. E.g.:

```
<div id="menu" popover>
  <button autofocus popoverhidetarget="menu">Button #1</button>
  <button popoverhidetarget="menu">Button #2</button>
</div>
```

In this case, trying to tab between the first and second button would
break because the second button appeared to be an invoker for a new
popover, when in reality it was an invoker for the same popover.

Fixed: 1399601
Bug: 1307772
Change-Id: I276370d7c8eee0dd32f0c89da202a0d3777bf911
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4133482
Commit-Queue: Mason Freed <[email protected]>
Auto-Submit: Mason Freed <[email protected]>
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Joey Arhar <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1089080}

…on discrete properties."

Original patch: https://crrev.com/c/4219315
Revert 1: https://crrev.com/c/4305045
Reland 1: https://crrev.com/c/4304846
Revert 2: https://crrev.com/c/4307944

Despite the most relaxed value in TestExpectations for
discrete-no-interpolation.tentative.html, some bots are still breaking
for reasons I don't understand. I am going to remove the test completely
until it stops crashing or failing. This patch will still be useful
despite the lack of tests because other people are doing prototyping
work that builds on this change.

Bug: 1399631, 1413556
Change-Id: Ic08f16d6436e37acc8947a94ca699c1735fe221f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4308075
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Auto-Submit: Joey Arhar <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1114026}

…sitions on discrete properties.""

This reverts commit 268250b.

…les transitions on discrete properties.""" (web-platform-tests#38936)

This reverts commit 78f70fd.

Most of the logic now lives on NaviagateEvent itself (in React()
and ReactDone()), which the new NavigateEvent::Reaction is a minimal
callback function wrapper.

Change-Id: Id31152b048fc7166a8ac45bda7e136a2143fd56f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4369772
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Nate Chapin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1123074}

…each time of the loop

There are 2 possible scenarios which are not handled by the method.

1. Moving content node to new `<blockquote>` has already been moved to outside
of the editing host.
2. There is no container to insert new `<blockquote>`, e.g., in an inline
editing host.

In the case #1, we should ignore the ex-child node.  In the case #2, we should
abort it.  Note that Chrome inserts `<blockquote>` even if there is no proper
container.  However, such behavior is disagreed in interop-2023.  Therefore,
it's okay just to abort it for now.

Depends on D180781

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

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1756237
gecko-commit: 42f3f3ab11b47f1d56d8bcd6a128398539dd1f23
gecko-reviewers: m_kato

…eb-platform-tests#40504)

* [wdspec] browsingContext.print: fix rounding error in page.py test

[pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py)
uses:

    def cm_to_px(cm): return round(cm * 96 / 2.54)

[js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html)
uses:

    const viewport = page.getViewport({ scale: 96. / 72. });
    ...
    canvas.height = viewport.height;
    canvas.width = viewport.width;

This produces a rounding error, even though the dimension is correct:

    >       assert cm_to_px(expected_dimensions["height"]) == height
    E       assert 454 == 453
    E         +454
    E         -453

The inconsistency of rounding in both ends becomes clear when we
eliminate "round" in the pytest side:

    >       assert cm_to_px(expected_dimensions["height"]) == height
    E       assert 453.54330708661416 == 453
    E         +453.54330708661416
    E         -453

There are multiple ways to fix this issue.

Option #1: Use "floor" instead of "round" in pytest.

Option #2: Use a range in the assertion comparison, allowing a
difference of up to +-1.0. This is what this PR does.

The comparison is performed in
[`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210).

The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333....

* use floor in cm_to_px instead of round

* compare to floor and to round instead of a range

* Revert "compare to floor and to round instead of a range"

This reverts commit 63f894e.

* Revert "use floor in cm_to_px instead of round"

This reverts commit 7e65d91.

This CL fixes a :has() invalidation bug when the following conditions
are met:

1. A style rule uses a :has() pseudo class. The :has() test result is
   affected by the anchor element's relationship to its sibling
   element at fixed distance. (e.g. '.a:has(+ .b) {}')
2. The :has() pseudo class was tested on an anchor element and it
   didn't matched.
3. If a sibling of the anchor element is removed, the :has() will
   match the anchor element.
   (e.g. '<div class=a></div><div id=target></div><div class=b></div>')
4. Remove a sibling of the anchor element so that the :has() matches
   the anchor element. (e.g. 'target.remove();')

For the removal, StyleEngine have to schedule :has() invalidation
even if the removed element doesn't have any identifier stored in
RuleFeatureSet. But it is not efficient to schedule :has()
invalidation for every element removal.

To avoid unnecessary :has() invalidation, StyleEngine checks whether
its parent has the 'ChildrenAffectedByDirectAdjacentRules' flag set
or not.

Currently, the SelectorChecker sets the flag only when it consumes
a direct adjacent combinator(+). This works most cases but it doesn't
work in this case (condition #2) because the SelectorChecker stops
the :has() argument selector matching before consuming the direct
adjacent combinator. Due to this, the parent of the anchor element
doesn't have the 'ChildrenAffectedByDirectAdjacentRules' flag set
and the StyleEngine doesn't schedule the :has() invalidation for the
removal.

To fix the error, when the SelectorChecker tests a :has() pseudo
class on an anchor element and the :has() is affected by the anchor
element's relationship to a sibling at fixed distance, the
SelectorChecker sets the flag of the parent to indicate that
StyleEngine need to schedule :has() invalidation whenever any child
of the element is removed.

Bug: 1480643
Change-Id: I5ec2e3c1db2773020368415f68bca1503367e669
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4864627
Commit-Queue: Byungwoo Lee <[email protected]>
Reviewed-by: Rune Lillesveen <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1198137}

…rners

We had two issues:
1.  Before we had fast rounded corners, we always created mask layers
for rounded corner clips, and the mask layer made the scroll begin
unreliable and fall back to the main thread. With fast rounded corners,
the scrolls were treated as reliable without checking if the point is
in or out of the rounded corners.
2. If the scroller has a rounded corner by itself (instead of from an
ancestor), as we only create InnerBorderRadiusClip for the contents,
the compositor doesn't actually know which part of the layer bounds
is transparent to hit test (e.g. if the scroller has a border which
is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness,
such layers have HitTestOpaqueness::kMixed.

This CL changes the behavior of
LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from
FindLayerUpToFirstScrollableOrOpaqueToHitTest):
- For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the
  layer is affected by any fast rounded corners;
- For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only
  OpaqueToHitTest() (without checking IsScrollerOrScrollbar())
  because a hit test on a scrollable layer is reliable only if it's
  opaque to hit test.

Bug: 40277896
Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909
Commit-Queue: Xianzhu Wang <[email protected]>
Reviewed-by: Steve Kobes <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1291538}

See https://drafts.csswg.org/css-pseudo-4/#first-text-line

1. For a block container that establishes an inline formatting context,
the "first formatted line" is its first line box, if it has one.
Otherwise, there is no first formatted line.

2. Otherwise, for a block container that has block children, look inside
the first in-flow block child (if any) and do #1 if it establishes an
inline formatting context. Otherwise, do #2.

In short, we don't need to search for line boxes in blocks after the
first block child. If there is no line in the first child, there's no
"first formatted line".

There's no spec for "last formatted line", but apply the same logic.
I.e. if the last block child has no line, there's no "last formatted
line".

This allows us to simplify things a bit, especially when it comes to
re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need
this now is for blocks inside inlines: If the last formatted line is
inside a block-in-inline, we need to go back and re-lay it out if it
turns out to be the last line (which isn't something we can check inside
block-in-inline layout). Note: When adding support for block
fragmentation, trimming at a fragmentainer's block end will be another
case where we need to re-lay out.

The motivation for this change was text box trimming inside block
fragmentation (upcoming CL), and be able to add support for that and
still be reasonably confident that it won't become too complicated.

This fixes one existing test. Some other existing tests had to be
updated because of this change (they were making incorrect assumptions
about first/last formatted line). As a result of that, some new refs had
to be added, since other tests were piggy-backing on the same ref.

Bug: 40254880, 367766472
Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979
Commit-Queue: Morten Stenshorne <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1373765}

This implements the core Sanitizer logic. This is still missing
spec-mandated handling of "javascript:" URLs, and will have to be
updated as the spec develops. But other than that, the basics are now
there.

------------------

This a re-land of crrev.com/c/5922125. Patch set #1 is the original version,
as reviewed and submitted there. Patch set #2 contains the fix. Analysis of
the bug is in https://issues.chromium.org/issues/356601280#comment16

Bug: 356601280, 379235386, 379246316
Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6021482
Reviewed-by: Yifan Luo <[email protected]>
Reviewed-by: Joey Arhar <[email protected]>
Commit-Queue: Daniel Vogelheim <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1385522}

This patch teaches the network service's `URLLoader` how to evaluate the
SRI-valid subset of HTTP Message Signatures, blocking mismatched
responses once headers are received and processed.

This check is implemented behind a new feature flag, which is disabled
by default. End-to-end tests live in web platform tests under
//web_tests/virtual/sri-message-signatures that enables the flag.

This is part of a chain of CLs implementing this feature (#2 from
https://wicg.github.io/signature-based-sri/#overview):

1.  [Parsing] https://crrev.com/c/6020612
2.  [Validation 1] https://crrev.com/c/6030571
3.  [Validation 2] https://crrev.com/c/6032589
4.  [Enforcement] https://crrev.com/c/6038714 [You are here]

    `url_loader.cc` are the only meaningful changes in behavior
    reported as undercovered. These are tested through the WPT
    included in this CL.

Bug: 379534943
Low-Coverage-Reason: COVERAGE_UNDERREPORTED The changes to
Change-Id: I6ece80da25ed4329a6f976c2c74c639c2799b856
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6038714
Reviewed-by: Kenichi Ishibashi <[email protected]>
Reviewed-by: Camille Lamy <[email protected]>
Reviewed-by: Kent Tamura <[email protected]>
Commit-Queue: Mike West <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1389294}

Make reporting of sourceFile, lineNumber, column more consistent

Changes the test so that it checks for nulls.

Added test (#2) that has script running and therefore should have source
information.

/content-security-policy/reporting-api/report-to-directive-allowed-in-meta.https.sub.html
also had the same problem, of expecting source code information with no
running javascript. Checks for null instead.

See https://w3c.github.io/webappsec-csp/#create-violation-for-global

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

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1909705
gecko-commit: cdb2d306e3f6e3c8e23075b67592682a91e8fcdb
gecko-reviewers: dom-core, smaug

To "prepare the script element" [1] exits early when the element is disconnected.
In this test, the script element represented by frag_script_2 which logs "inline script #3"
is disconnected in the preceeding script (frag_script_1 / "inline script #2").
Since post-connection steps [2] are executed in the tree order, by the time we are to
"prepare the script element" on frag_script_2 / "inline script #3", the script element is
already disconnected and the script will not be executed.

This test failing in Chrome and Safari but passing in Firefox. After the change, the test
passes in Chrome and Safari and fails in Firefox.

[1] https://html.spec.whatwg.org/multipage/scripting.html#prepare-the-script-element
[2] https://dom.spec.whatwg.org/#concept-node-post-connection-ext

…s#58514)

To "prepare the script element" [1] exits early when the element is disconnected.
In this test, the script element represented by frag_script_2 which logs "inline script #3"
is disconnected in the preceeding script (frag_script_1 / "inline script #2").
Since post-connection steps [2] are executed in the tree order, by the time we are to
"prepare the script element" on frag_script_2 / "inline script #3", the script element is
already disconnected and the script will not be executed.

This test failing in Chrome and Safari but passing in Firefox. After the change, the test
passes in Chrome and Safari and fails in Firefox.

[1] https://html.spec.whatwg.org/multipage/scripting.html#prepare-the-script-element
[2] https://dom.spec.whatwg.org/#concept-node-post-connection-ext