Sync with W3C

Catch up to W3C

…set #1 id:1 of https://codereview.chromium.org/2651533003/ )

Reason for revert:
This commit was intended to be reverted to test how WPT Export handles reverted changes. See the bug for more context.

Original issue's description:
> Create a change in external/wpt meant to be reverted
>
> This is to test reverted changes in the WPT Export process.
>
> BUG=679951
>
> Review-Url: https://codereview.chromium.org/2651533003
> Cr-Commit-Position: refs/heads/master@{#445651}
> Committed: https://chromium.googlesource.com/chromium/src/+/b156b16a00574a89d85ccb034b30cdfd9cc5676a

TBR=qyearsley@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=679951

Review-Url: https://codereview.chromium.org/2657613002
Cr-Commit-Position: refs/heads/master@{#445762}

Revert of Create a change in external/wpt meant to be reverted (patchset #1 id:1 of https://codereview.chromium.org/2651533003/ )

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}

Remove AILanguageDetectorFactory and expose create and availability
statically on LanguageDetector.

This is a followup change to CLs crrev.com/c/6402873,
crrev.com/c/6402775.

Note: This change is a cherry-pick of crrev.com/c/6397965.
Some changes have been made as part of rebasing + fixing previous
CQ test failures. PS #1 represents the cherry-picked change prior
to rebase + minor edits.

Fixed: 402165734
Change-Id: Id384ebe31ccfe9e0efd65dd7c890cd66875a9ed8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6403274
Reviewed-by: Mike Wasserman <msw@chromium.org>
Commit-Queue: Christine Hollingsworth <christinesm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1439000}

This is a preparation change to the upcoming change that disallows
non-trustworthy plaintext HTTP prerendering.

This CL now runs external/wpt/speculation-rules/ wpts over HTTPs.

Bug: 340895233
Change-Id: Id820f192f5e973245c2dbbf1ca8daa5078abad78
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6398184
Reviewed-by: Domenic Denicola <domenic@chromium.org>
Reviewed-by: Fabio Rocha <fabio.rocha@microsoft.com>
Commit-Queue: Jessica Chen <peiche@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1450755}

…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415)

Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1.

Credits to JDM for actually pointing out which functions to fix.

Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html
Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>

…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415)

Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1.

Credits to JDM for actually pointing out which functions to fix.

Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html
Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>

…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415)

Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1.

Credits to JDM for actually pointing out which functions to fix.

Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html
Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>

…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415)

Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1.

Credits to JDM for actually pointing out which functions to fix.

Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html
Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>

…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415)

Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1.

Credits to JDM for actually pointing out which functions to fix.

Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html
Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>

…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415)

Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1.

Credits to JDM for actually pointing out which functions to fix.

Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html
Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>

…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415)

Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1.

Credits to JDM for actually pointing out which functions to fix.

Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html
Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>

…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415)

Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1.

Credits to JDM for actually pointing out which functions to fix.

Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html
Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>