Update from W3C master

Catch up to W3C master

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 <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
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 <lyf@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
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 <bashi@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
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