chromedriver doesn't allow changing Object.prototype to add enumerable
properties, but this test requires setting some values on
Object.prototype.  When Object.prototype.a is set to:

  {b: {c: 'on proto'}}

chromedriver fails with:

    JavascriptErrorException: javascript error (500): Maximum call stack size exceeded
      (Session info: chrome=72.0.3626.121)

    Remote-end stacktrace:

    #0 0x563ff3a32a59 <unknown>
    #1 0x563ff39cb7f3 <unknown>
    #2 0x563ff38fcd7c <unknown>
    #3 0x563ff38ff78c <unknown>
    #4 0x563ff38ff5f7 <unknown>
    #5 0x563ff38ffbe7 <unknown>
    #6 0x563ff38fff1b <unknown>
    #7 0x563ff38a3f7a <unknown>
    #8 0x563ff3899bf2 <unknown>
    #9 0x563ff38a37b7 <unknown>
    #10 0x563ff3899ac3 <unknown>
    #11 0x563ff38782d2 <unknown>
    #12 0x563ff3879112 <unknown>
    #13 0x563ff39fe865 <unknown>
    #14 0x563ff39ff32b <unknown>
    #15 0x563ff39ff70c <unknown>
    #16 0x563ff39d940a <unknown>
    #17 0x563ff39ff997 <unknown>
    #18 0x563ff39e9947 <unknown>
    #19 0x563ff3a1a800 <unknown>
    #20 0x563ff3a3c8be <unknown>
    #21 0x7f3bf4545494 start_thread
    #22 0x7f3bf2d58a8f clone

    Ran 1 tests finished in 2.0 seconds.
      • 0 ran as expected. 0 tests skipped.
      • 1 tests had errors unexpectedly

Work around this problem by cleaning up the test environment so
Object.prototype no longer has the override by the time chromedriver
tries to inspect the test result.

While here, fix the other tests to use the t.add_cleanup() function
so they'll cleanup their test environment in case they exit in
some other way besides reaching t.done().

The underlying chromedriver issue is tracked upstream at
https://crbug.com/chromedriver/2555.

Bug: 934844
Change-Id: Id1b4ab2a908bfbc001e2a2d045eeec3ef01c24d9

All tests pass, and crashes no longer happen. I believe
that code will not longer crash, but there might be
futher instances of incorrect positioning.

Fix #1
LayoutDescendantCandidates did not sweep newly discovered
candidates. This was done
manually once inside NGOutOfFlowLayoutPart::Run, and
sweep was not performed for LayoutDescendantCandidates
found in Legacy. Fix is to make LayoutDescendantCandidates
perform sweep instead.

Fix #2
fix #1 exposed a bug where duplicate fragments were generated
for a single layout object. This happened when NG was generating
fragments not inside ContainingBlock. Fix one instance of this
inside NGOutOfFlowLayoutPart::IsContainingBlockForDescendant
by making sure that OOF with inline containers are only positioned
inside its ContainingBlock()

Fix #3
NGOutOfFlowLayoutPart::LayoutDescendant offset adjustment.

Bug: 935805
Change-Id: I9f7ebbc7223f40fbbf6ba3739d9385bfd59e3641
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1517093
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#641628}

…eVisibilityKeeper::PrepareToSplitBlockElement()` before splitting a text node

It does the following things when caret is collapsed in a text node in a `<p>`
or `<div>` element.

1. Split the text node containing caret to insert `<br>` element
2. Insert `<br>` element after it
3. Split ancestor elements which inclusive descendants of the `<p>` or `<div>`
4. Delete the `<br>` element if unnecessary from the left paragraph

#3 and #4 are performed by `HTMLEditor::SplitParagraph()` and it calls
`WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` correctly before
splitting the block.  However, in the case (caret is at middle of a text node),
the text has already been split to 2 nodes because of #1.  Therefore, it fails
to handle to keep the white-space visibility.

So that I believe that the root cause of this bug is, the method does much
complicated things which are required, and doing the redundant things will
eat memory space due to undo transactions.  However, for now, I'd like to fix
this with a simple patch which just call the preparation method before splitting
the text node because I'd like to uplift this if it'd be approved (Note that
this is not a recent regression, the root cause was created by bug 92686 which
was fixed in 17 years ago:
<https://searchfox.org/mozilla-central/commit/2e66280faef73e9be218e00758d4eb738395ac83>,
but must be annoying bug for users who see this frequently).

The new WPTs are pass in Chrome.

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

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1740416
gecko-commit: 73567f6c2bcfa078836a36760498bb11747561dd
gecko-reviewers: m_kato, smaug

This CL improves the testing of template cloning with Parts, testing
these four cases:

  1. Main document parsing
  2. Template (content fragment) parsing
  3. Template/fragment cloning
  4. Declarative Shadow DOM parsing and cloning

This CL fixes the behavior for #3 above, but leaves #4 broken. The
following changes in behavior are made:

1. Part::MoveToRoot() can be used to change the root(), including
   to set it to nullptr. This happens when a Node tree is removed
   from the DOM, and it contains Parts that refer to the old root.
2. IsDocumentPartRoot() is now virtual, because during a tree move,
   the root() for a Part can be made nullptr even when it's a
   ChildNodePart.
3. Part::disconnected_ is added to keep track of whether the
   Part has been disconnected, since root() can now be nullptr.
4. (This is a bug fix) When using ChildNodePart::setNextSibling(),
   the new sibling node wasn't having its Part registered with
   NodeRareData, which caused a CHECK failure when trying to
   subsequently clone that Part. This is caught in the new test
   which clones declaratively-built templates containing Parts.

Bug: 1453291
Change-Id: Ic1c1475431cf6bd658f191db78003204412ef78f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4713668
Reviewed-by: David Baron <dbaron@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175782}

Following the discussion on issue #3 [1], this CL adds support to soft
navigations triggered by keyboard shortcuts, by adding unfocused keydown
events to the events that can trigger the soft navigation heuristic.

[1] WICG/soft-navigations#3

Bug: 1478772
Change-Id: Ib423a3cfc09eaf4dd9a2221b3494ab1016fa8668
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4839506
Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1193004}

…on triggers"

This reverts commit 6efe71286a014d3d3872bc990e3ea2d08dd46dba.

Reason for revert: One check added in this CL causes crash. see
crbug.com/1480047

Original change's description:
> [soft navigations] Enable keyboard shortcuts as soft navigation triggers
>
> Following the discussion on issue #3 [1], this CL adds support to soft
> navigations triggered by keyboard shortcuts, by adding unfocused keydown
> events to the events that can trigger the soft navigation heuristic.
>
> [1] WICG/soft-navigations#3
>
> Bug: 1478772
> Change-Id: Ib423a3cfc09eaf4dd9a2221b3494ab1016fa8668
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4839506
> Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
> Reviewed-by: Ian Clelland <iclelland@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1193004}

Bug: 1478772
Change-Id: I3a518c165e6b19239a6bf7900e94c1ef9c3e5a5a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4859802
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Commit-Queue: Hao Liu <haoliuk@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1196100}

…on triggers

Following the discussion on issue #3 [1], this CL adds support to soft
navigations triggered by keyboard shortcuts, by adding unfocused keydown
events to the events that can trigger the soft navigation heuristic.

This is a reland of [2], rebased and which fixes the unguarded
ScriptState access in event_dispatcher, which caused a crash.

[1] WICG/soft-navigations#3
[2] https://chromium-review.googlesource.com/c/chromium/src/+/4839506

Bug: 1478772, 1480047
Change-Id: I6428e0635222366d880dd908f04f2273b6bf8b44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4900577
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1203903}

…attempt #3

This converts IDL-exposed promises in ReadableStream,
ReadableStreamBYOBReader, ReadableStreamDefaultReader, and
ReadableStreamGenericReader to use typed ScriptPromiseResolver
instead of StreamPromiseResolver and to return typed
ScriptPromises.

Bug: 329702363
Change-Id: I8ad1af1a7c9c909d711881ce7621c6c9fac58931
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5429731
Reviewed-by: Adam Rice <ricea@chromium.org>
Reviewed-by: Nidhi Jaju <nidhijaju@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1289397}

Since @page border box layout objects aren't in the the layout tree, any
code that wants to walk up the tree to find the containing block will be
in for a surprise.

This would happen if percentage-based @page padding was used [1].
Recomputing padding during painting when we have already done it during
layout is rather pointless anyway. Read it out directly from the
fragment.

[1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent()
    #2 blink::LayoutBoxModelObject::ComputedCSSPadding()
    #3 blink::LayoutBoxModelObject::PaddingTop()
    #4 blink::LayoutBoxModelObject::PaddingOutsets()
    #5 blink::BoxPainterBase::PaintFillLayer()
    #6 blink::BoxPainterBase::PaintFillLayers()
    #7 blink::BoxFragmentPainter::PaintBackground()

Bug: 40286153
Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1300711}

Fixing these tests involved the following updates:
1. Update all grid id refs to masonry.

2. In the row test, update the item.style.expectedRows to
item.style.gridRow. I suspect this was a bad AI suggestion I didn't
catch originally.

3. The min-content/max-content contribution in the block direction
(i.e. row direction) is always the same (which is the block content
contribution). This means that the row test expectations needed to
be updated for all min-content entries to match that of max-content.

The reason the grid test for #3 is different is that test sets both
column and row constraints, which impacts what the rows are sized to.
In this case, we are only constraining the row sizes, so we can end
up with different expectations as a result.

Bug: 343257585
Change-Id: I81f19a30d332eab5e18b7638d98467fbb81cde02
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7038202
Commit-Queue: Alison Maher <almaher@microsoft.com>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1532680}