AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The existing calculation will make them overlap. The AdjustOverlappingScrollbars code was written with overlay scrollbars in mind but it looks like it will work just fine for this case.
Differential Revision: https://phabricator.services.mozilla.com/D85707
Otherwise the calculation above would lead to an empty rect for the scroll corner.
The scrollbar rects as computed now still overlap each other and the scroll corner, the next patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D85706
There is no dependency in this code as far as I can tell.
The next patch needs the scrollbar rects for the scroll corner calculation.
Differential Revision: https://phabricator.services.mozilla.com/D85705
Layout scrollbars that were only created for the visual viewport had no space reserved for them, so we need to shift them back in like overlay scrollbars. Otherwise they sit just outside of the scroll port and are not visible.
Differential Revision: https://phabricator.services.mozilla.com/D85704
For the former we are still allowed to show scrollbars if we need to scroll the visual viewport inside the layout viewport (as long as they take up no layout space). For the latter we still do not want to show scrollbars.
The ShowScrollbar enum is now only from layouts perspective and doesn't take into account anything about the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D85700
This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches.
The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport).
In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed).
Differential Revision: https://phabricator.services.mozilla.com/D85699
Creation cost of `nsRange` is expensive, and it's only user,
`HTMLEditor::HandleDeleteNonCollapsedRanges()` wants to extend the range.
Therefore, we can make it directly extend the given range.
Differential Revision: https://phabricator.services.mozilla.com/D85849
It may be faster to use `AutoTrackDOMRange` directly. Therefore, current
`WhiteSpaceVisibilityKeeper::PrepareToDeleteRange()` should be renamed to
`WhiteSpaceVisibilityKeeper::PrepareToDeleteRangeAndTrackPoints()` and
we should make `HTMLEditor::HandleDeleteNonCollapsedSelection()` track
the range by itself.
Depends on D85846
Differential Revision: https://phabricator.services.mozilla.com/D85847
There is only `AutoTrackDOMPoint`, but
`HTMLEditor::HandleDeleteNonCollapsedSelection()` requires to tack pairs of
DOM points, i.e., requires to track ranges. For making the code simpler,
we should have range tracker too.
Depends on D85845
Differential Revision: https://phabricator.services.mozilla.com/D85846
This is very simple, but it gets the job done. It keeps a map in `UrlbarInput`
from browsers to search mode objects. The map is updated in `setSearchMode`, and
it's used to set the search mode in `_afterTabSelectAndFocusChange`.
Differential Revision: https://phabricator.services.mozilla.com/D86296
This is a narrow fix to the bug, which happens because I removed this
conditional in bug 1654439: https://hg.mozilla.org/mozilla-central/rev/f561eb606ad3#l1.251
That conditional kept the selection out of the one-offs when the urlbar hid
them. This patch replaces that conditional with a version that can be overridden
by the urlbar subclass. It adds a `hasView` getter that is equivalent, but note
that `this._view` can't be used because the urlbar subclass sets `this.view` in
its constructor and never nulls it out, unlike the original implementation. So
instead the subclass `hasView` checks whether the one-offs are hidden. This is
effectively the same thing because in the old implementation the urlbar one-offs
were hidden at the same time `this._view` was nulled out.
Differential Revision: https://phabricator.services.mozilla.com/D86293
When a clearance frame is discovered in a BFC
subtree (`ReflowInput::WillReflowAgainForClearance()` is true), all the
block descendants of the BFC return from `ReflowBlockFrame` immediately
without placing their children or requesting continuation for their
children, etc., because the BFC is going to reflow the subtree a
second time.
When this happens, any block descendant whose lines contain pushed
floats should be marked dirty and reflowed again so that they can go
through all the split floats logic and set their nsReflowStatus to
incomplete/overflow-incomplete correctly. (We may develop a smarter way
in bug 851629 to make the performance better.)
The condition `aState.mPresContext->IsPaginated()` is added to prevent
1406291-1.html from failing. In 1406291-1.html, the table containing the
float in its subtree is being pushed to the second page due to force
break, and the float is in PushedFloatsList of its parent block. When we
reflow the block again (in the second page), it is reflowed under the
measuring stage of the table layout with unconstrained available
block-size. nsBlockFrame::DrainSelfPushedFloats() deliberately doesn't
drain pushed floats if their placehoder are in the same block, and
expect the floats to be reflowed again. Before this patch, the line can
be marked dirty via HasPushedFloats(), but in this patch,
HasPushedFloats() is moved into the nested if-else, so we need
`aState.mPresContext->IsPaginated()` to let the block know that it's in
a paginated context, and needs to reflow any line that contains pushed
floats.
Differential Revision: https://phabricator.services.mozilla.com/D85480
Before this patch, a block frame considers a line dirty only if the line's
block-end is larger than content area's block-end.
However, scrollable overflow area should be broken in paginated environment
(both in a column container and in printing). We should take this into account
when marking a line dirty.
The dynamic wpt reftests are written with the following conditions in mind to
expose the bug:
1. Initially, all the elements fit into the first column.
2. After shrinking the multicol height, the block itself still fits into
the first column, but its tall child (either a simple tall block or a
tall float), which overflows the smaller multicol height, needs to be
broken.
The flexbox printing reftest are similar. A flex container uses
unconstrained available block-size to measure flex items' block-size,
and then performs a final reflow with constrained available block-size,
which is similar to the dynamic scenario above. One caveat is that flex
items usually have IsBResize() set. So to expose this bug, a float
element needs to be deeply nested under a flex item.
Differential Revision: https://phabricator.services.mozilla.com/D85479
Automatic update from web-platform-tests
[WPT] Errors caught/reported for importScripts() (#24810)
This CL adds WPTs for exceptions in importScripts() captured by
- WorkerGlobalScope error event handler or
- try/catch.
Some of the tests are migrated from non-WPT web_tests.
The tests are failing on Chromium right now, and will pass
after
https://chromium-review.googlesource.com/c/chromium/src/+/2328394/.
Bug: 1111134, 1111750, 795636
Change-Id: Ie19085171261d4baf307b6544ff6a8da1a8e9041
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2327787
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Domenic Denicola <domenic@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/master@{#794474}
Co-authored-by: Hiroshige Hayashizaki <hiroshige@chromium.org>
--
wpt-commits: 059a8ae79c2c44ef2eda3ccb412b0773e99c26b6
wpt-pr: 24810
Automatic update from web-platform-tests
[TrustedTypes] WPT test > check violation's sourceFile.
Check what is the reported sourceFile depending on the script's origin.
Currently, the full URL isn't exposed in the case of a cross-origin
script. This is an issue. See https://crbug.com/1113163
TODO: Add checks with redirects.
Bug: 1113163
Change-Id: I8bbd1234a485568127a21c6abfbd4d4a623494f2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2341125
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#795841}
--
wpt-commits: af3059a547d3843001ed2aa7537418f1c9850c92
wpt-pr: 24905
Automatic update from web-platform-tests
content-visibility: Add a (failing) test for composited descendant bug.
This patch lands a test and marks it as failing. Since the solution
to this bug doesn't seem obvious yet (see the referenced bug), we
should land the test so any of the potential fixes can be verified on
the bots.
R=chrishtr@chromium.org, wangxianzhu@chromium.org
Bug: 1113838
Change-Id: I410766ce8294309840ca21945c3b231c018825aa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2341356
Commit-Queue: vmpstr <vmpstr@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#795770}
--
wpt-commits: 688aeffbd02c1e05a159c64938ad9b43e3d8ec6e
wpt-pr: 24909
Automatic update from web-platform-tests
[css-flex] Update test to wait for image load before checking sizes
This test flaked on me locally with:
height expected 100 but got 0
Which is consistent with calling checkLayout before the image has
loaded, but not a guarantee that's what's happening. I haven't been able
to reproduce it.
In any case, this change can't hurt.
Change-Id: I1bf8ccb935845c6e5e4529694c2d77e3f4a529a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2340735
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#795652}
--
wpt-commits: 4afc499e300020a425144d8a6034abc75efa1e17
wpt-pr: 24906
Automatic update from web-platform-tests
Update tests for forced breaks at fragmentainer start.
If there's a forced break, and it's at a valid class A breakpoint, we
may break there. There's nothing in the spec suggesting otherwise.
This is working correctly in the LayoutNG fragmentation engine, but not
in the legacy engine (where we require some non-zero block-size content
to allow forced breaks). Remove invalid tests, and add a couple of valid
ones.
Bug: 1100849
Change-Id: I1829a00a4e9761906ebe4536ded9c994f4737e69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2339663
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#795604}
--
wpt-commits: c7c27f9106d063ad4764aacdef5cb472c4be676e
wpt-pr: 24907
Automatic update from web-platform-tests
[Fixup] discord web app doesn't work because of getPointAtLength
Remove |EnsureComputedStyle| on SVGPathElement::getPointAtLength.
Although <path> is in an inactive document, <path> element can compute
the total length of path. Because the equivalent path of a ‘path’
element is simply the path itself.
Bug: 972979, 1108966
Change-Id: I5194352c1d4452dacc721f3ae223019998859d13
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2339714
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#795584}
--
wpt-commits: dd51bfa9ef3b7d7494c1c492707b11fece103c14
wpt-pr: 24893
Automatic update from web-platform-tests
[taskcluster] Schedule Chrome Nightly epochs/daily
as well as triggers/chrome_nightly
The task will install Chromium ToT automatically.
--
wpt-commits: ee8019795741475935690c58b6e24a10a918ba55
wpt-pr: 24904
Automatic update from web-platform-tests
[css-flex] Add regression test for abspos bug fixed in FlexNG
The test is minimally altered from the repro in the bug. It fails when I
disable FlexNG, but passes in Chrome 84 and Firefox.
Fixed: 886592
Change-Id: Ieb7be3619c0095c185b405703c384864d9046cd5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2337416
Commit-Queue: David Grogan <dgrogan@chromium.org>
Auto-Submit: David Grogan <dgrogan@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#795264}
--
wpt-commits: fa1a6d1c3cc2665385a9a5bd84e2dd0352e82868
wpt-pr: 24881
Automatic update from web-platform-tests
Python 3: Use OrderedDict type to generate same test names
In Python 2, dict is organized via a hash-table and puts the keys
into buckets according to their hash() value.
in Python 3.6+, dict retains insertion order
This patch uses OrderedDict type instead the original Dict to make
sure the same test names generated for both PY2 and PY3
--
wpt-commits: 497a4d7b57486a9e973aff814d9c1d46936ee6f9
wpt-pr: 24874