Translate the scroll coordinate to ScrollOrigin #17851
Merged
Conversation
|
Already reviewed downstream. |
chromium-wpt-export-bot
changed the title
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
2 times, most recently
from
b15cf19
to
b14896f
chromium-wpt-export-bot
changed the title
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
2 times, most recently
from
5dfe101
to
196bfd5
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
4 times, most recently
from
88cd8e5
to
865ca18
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
from
865ca18
to
1f0f501
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
3 times, most recently
from
b5f1f0c
to
25e3316
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
2 times, most recently
from
2e8bb6b
to
f43baed
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
4 times, most recently
from
1bc2e2f
to
c19afe7
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
5 times, most recently
from
3f61a9f
to
ce328c4
Currently, the value of ScrollLeft / ScrollTop / ScrollTo for a box in Element is the offset to the origin of ScrollableArea(left-top corner). This behavior isn't consistent with Document-scroll or the behavior of other vendors either whose origin is ScrollOrigin. There're compatibility problems when the box has leftward or upwards scroll overflow direction. According to the Specification, the scroll x-coordinate of a leftward box is nonpositive, and the scroll y-coordinate of an upwards box is also nonpositive. With using the origin of ScrollableArea, the coordinate is always nonnegative. In order to fix it, this patch transforms the scroll coordinate of a box in Element interface to use ScrollOrigin as its origin. There are a few cases needed to recalculate the scroll coordinate to meet this change. Since the origin of scroll coordinate transforms from the ScrollableArea origin to ScrollOrigin(), current_coordinate is equal to old_coordinate - ScrollOrigin. E.g. current_scrollLeft = old_scrollLeft - ScrollOrigin().X(). This behavior is guarded by a feature flag. See intent to ship blink-dev thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7X2CKPGeEa0 Bug: 721759 Change-Id: I0ceed62e6845c6e5cd976e59b36f292d60bb669c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1700001 Reviewed-by: Jochen Eisinger <jochen@chromium.org> Reviewed-by: David Bokan <bokan@chromium.org> Reviewed-by: Frédéric Wang <fwang@igalia.com> Commit-Queue: cathie chen <cathiechen@igalia.com> Cr-Commit-Position: refs/heads/master@{#704470}
chromium-wpt-export-bot
force-pushed the
chromium-export-cl-1700001
branch
from
ce328c4
to
022536f
chromium-wpt-export-bot
merged commit 3001893
into
master
13 checks passed
13 checks passed
Azure Pipelines (affected tests without changes: Safari Technology Preview)
affected tests without changes: Safari Technology Preview succeeded
Details
Azure Pipelines (affected tests: Safari Technology Preview)
affected tests: Safari Technology Preview succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests)
wpt.fyi hook: safari-preview-affected-tests succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests-without-changes)
wpt.fyi hook: safari-preview-affected-tests-without-changes succeeded
Details
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Currently, the value of ScrollLeft / ScrollTop / ScrollTo for a box in
Element is the offset to the origin of ScrollableArea(left-top corner).
This behavior isn't consistent with Document-scroll or the behavior of
other vendors either whose origin is ScrollOrigin. There're compatibility
problems when the box has leftward or upwards scroll overflow direction.
According to the Specification, the scroll x-coordinate of a leftward box
is nonpositive, and the scroll y-coordinate of an upwards box is also
nonpositive. With using the origin of ScrollableArea, the coordinate
is always nonnegative.
In order to fix it, this patch transforms the scroll coordinate of a
box in Element interface to use ScrollOrigin as its origin.
There are a few cases needed to recalculate the scroll coordinate to
meet this change. Since the origin of scroll coordinate transforms
from the ScrollableArea origin to ScrollOrigin(), current_coordinate
is equal to old_coordinate - ScrollOrigin. E.g.
current_scrollLeft = old_scrollLeft - ScrollOrigin().X().
This behavior is guarded by a feature flag.
See intent to ship blink-dev thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7X2CKPGeEa0
Bug: 721759
Change-Id: I0ceed62e6845c6e5cd976e59b36f292d60bb669c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1700001
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Frédéric Wang <fwang@igalia.com>
Commit-Queue: cathie chen <cathiechen@igalia.com>
Cr-Commit-Position: refs/heads/master@{#704470}