Automatic update from web-platform-tests
[FragmentItem] Limit reusing cached lines only when top-level child is clean
This patch simplifies |DirtyLinesFromNeedsLayout| to check
|NeedsLayout| of top-level children only.
The previous code tried to reuse more lines, e.g.:
<div><span>many lines of text</span></div>
Most lines are reusable when appending to the end of "text".
But supporting this case complicates the logic, especially
when culled inline is involved.
The new logic can't reuse lines in the above case, but still
can reuse liens if the `<span>` does not exist, and should
cover most common cases.
Bug: 1102083
Change-Id: I4f76e154b834c8c00e5ce04ab251c4f1fcdabab0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2282821
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#785345}
--
wpt-commits: eae9c1b62560eedbccc8efa3a1f6b6ce1ba97b30
wpt-pr: 24453
Automatic update from web-platform-tests
[FragmentItem] Fix DirtyLinesFromNeedsLayout
This patch fixes a case where |DirtyLinesFromNeedsLayout|
fails to mark items dirty for reusing cached lines.
When searching for |LayoutObject| needing layout, checking
|NormalChildNeedsLayout| and |PosChildNeedsLayout| were not
enough. In some specific cases, only
|NeedsSimplifiedNormalFlowLayout| was set for the parent
inline box.
This patch changes the condition to check descendants to
|NeedsLayout|.
Bug: 1101883
Change-Id: Ia73ace058c9ea1ebaaffdaff793b56d68099cd5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2281781
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#785287}
--
wpt-commits: aef9da08fe2fa0b9fa473e2e126cb3cf29fae43e
wpt-pr: 24444
Automatic update from web-platform-tests
[TablesNG] New test suite: colspan redistribution
Investigation into how cells with colspan > 1
redistribute their min/max/% widths.
Browsers often disagree, and spec allows for variations.
Bug: 958381
Change-Id: I588053d1392e00e9d199cdd1095b93a148101fc4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2219093
Reviewed-by: David Grogan <dgrogan@chromium.org>
Commit-Queue: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#785260}
--
wpt-commits: 6f5097d7cb5bcedef39dcdd5331064eadfdd0283
wpt-pr: 23807
Automatic update from web-platform-tests
[COOP] Report-only navigation tests (#24379)
This adds basic tests of the report-only features for the navigation
case, where the report-only headers would cause a browsing context
group switch.
Bug: 1099208
Change-Id: Ia5261d5d1ddac4a83943e0a48b5ef5f2cdb47b7b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2266000
Commit-Queue: Pâris Meuleman <pmeuleman@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Auto-Submit: Pâris Meuleman <pmeuleman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#785021}
Co-authored-by: Pâris MEULEMAN <pmeuleman@chromium.org>
--
wpt-commits: b7938227eacdc8d6d475c5a7bff061724d6ebd3f
wpt-pr: 24379
Automatic update from web-platform-tests
Test media features that are false in the negative range (#24433)
See https://github.com/w3c/csswg-drafts/issues/1454
--
wpt-commits: 6b786f18589c7407b7b804c883b5d5cbf254c086
wpt-pr: 24433
Automatic update from web-platform-tests
Add a @page margins test for print-reftests
This ensures that the 0.5" margin can be overriden when using a
print-reftest.
--
wpt-commits: 1ddd94983862011804dac3271eebd69160bee52b
wpt-pr: 24342
For making `WSRunScanner::BoundaryData` independent from `WSRunScanner`,
its initializer should be in the class itself as static factory methods.
Depends on D82295
Differential Revision: https://phabricator.services.mozilla.com/D82693
Now, we can call `WSFragment` `VisibleWhiteSpacesData`. Then, the methods of
`WSRunObject` which take `WSFragment` as their arguments become clearer what
they mean.
Differential Revision: https://phabricator.services.mozilla.com/D82295
Now, `WSFragment` instances are created only by
`TextFragmentData::CreateWSFragmentForVisibleWhiteSpaces()`. Therefore, it's
always visible.
Additionally, this patch hides `WSFragment` constructors from the others too.
Differential Revision: https://phabricator.services.mozilla.com/D82294
Now, we know that it returns `WSFragment` for visible white-spaces and may
lie position in the line. Therefore, we should rename it as just representing
visible white-spaces.
Differential Revision: https://phabricator.services.mozilla.com/D82292
Now, nobody uses `WSRunScanner::FindNearestRun()` so that we can remove it.
Then, there is no users of `WSRunScanner:mFragments`. Therefore, we can remove
the member, accessors and initializers.
Differential Revision: https://phabricator.services.mozilla.com/D82291
Unfortunately, remaining code which use `beforeRun` and `afterRun` of
`WSRunObject::PreareToDeleteRangePriv()` is completely broken. It tries to
do what the new utility methods say, but as you see in the method, the
checking code does not make sense. For now, we should keep this broken
check even with the expensive DOM point comparisons. I hope that this does
not harm any benchmark score.
Note that I tested this with all automated tests with comparing the result
of these methods with `MOZ_ASSERT()` like this:
https://hg.mozilla.org/try/rev/29cb7840e404473a41d2d1fbdd229f762ccac5d3
So, I think that this is enough safe because the most edge cases are tested
by the first patch in this bug and `editing/run/(forwarddelete|delete).html`
of WPT.
Differential Revision: https://phabricator.services.mozilla.com/D82290
Similar to the previous changes, `WSRunObject::PrepareToDeleteRangePriv()`
can use `TextFragmentData::CreateWSFragmentForVisibleAndMiddleOfLine()` and
result of comparing with deleting range.
Differential Revision: https://phabricator.services.mozilla.com/D82288
For handling composition, `WSRunObject::InsertText()` rescan white-spaces at
end of replacing range. However, in most cases, `mScanStartPoint` and
`mScanEndPoint` are same. Therefore, we can save the runtime cost of the
rescan easier than the old design.
Differential Revision: https://phabricator.services.mozilla.com/D82287
I realized that `WSFragment::MarkAsVisible()` is called only by
`TextFragmentData::CreateWSFragmentForVisibleAndMiddleOfLine()`. Therefore,
`beforeRun && !beforeRun->IsStartOfHardLine() && beforeRun->IsVisible()` can be
handled with `pointPositionWithVisibleWhiteSpacesAtStart` and
`afterRun && !afterRun->IsEndOfHardLine() && afterRun->IsVisible()` can be
handled with `pointPositionWithVisibleWhiteSpacesAtEnd`. So, we can make
`WSRunObject::InsertText()` stop using `FindNearestFragment()` to compute
inserting string.
Differential Revision: https://phabricator.services.mozilla.com/D82286
Sync dispatch are being used; due to how the background taskqueue is setup this could cause a hang if if also called from a background taskqueue.
Differential Revision: https://phabricator.services.mozilla.com/D82500
It worked until now as IPC's MessageChannel was only used with background taskqueue; which use a threadpool made of a single thread only.
Differential Revision: https://phabricator.services.mozilla.com/D82499
This patch moves the remote type crash annotation code from RecvSetProcessSandbox() to
RecvRemoteType(), where we actually set the remote type. This matters because
RecvSetProcessSandbox() only happens once when the process is created. If the process
is a preallocated process, it will get its remote type updated later, so we need to
also update the annotation.
It seems odd that we were setting the remote type annotation in a method related to
the sandbox and not where we set the remote type. My only guess is that prior to
bug 1332522 RecvSetProcessSandbox() happened first, so maybe they wanted to make sure
the annotation was set as early as possible. At that point in time, the remote type
never changed, so it was okay to just set it wherever, as early as possible.
Anyways, after that bug, the first call to RecvRemoteType() happens earlier, so this
change is strictly better.
I also fixed a typo in ContentParent.
Differential Revision: https://phabricator.services.mozilla.com/D82625