New wpt failures in /css/css-viewport/zoom/scroll-top-test-with-zoom.html
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: wpt-sync, Unassigned)
References
Details
(Whiteboard: [wpt])
Syncing wpt PR 45707 found new untriaged test failures in CI
Tests Affected
Firefox-only failures
- /css/css-viewport/zoom/scroll-top-test-with-zoom.html [wpt.fyi]
- scrollTop after increasing zoom level:
FAIL
- scrollTop after increasing zoom level:
CI Results
Gecko CI (Treeherder)
GitHub PR Head
Notes
These updates will be on mozilla-central once bug 1891429 lands.
Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.
This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/
If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.
|
||
Comment 1•5 months ago
|
||
emilio, maybe you could take a look if you've got cycles for another zoom issue?
|
||
Comment 2•5 months ago
|
||
I'm not sure I agree with this test's expectation? It was introduced in here which is an issue with browser zoom, but I'm not sure what in the CSS zoom property spec arrives to this behavior of scroll{Top,Bottom} not changing when the zoom property changes, just like when the size of the element changes...
I guess that's a reasonable thing to do (just keep scroll offsets in zoomed css pixels), but that's not easy to do in Gecko I think, nor specified...
|
||
Comment 3•5 months ago
|
||
That particular test doesn't really care about the value when zoom is changed to 1.2, the key for the issue is that when it's back to 1 we're not in a different position. Otherwise (and depending on the values of zoom it caused an infinite scroll just changing zoom (which seems clearly a bug). So we could remove that assert in the test and just keep the other initial and last one. I guess we agree that when we're back in zoom: 1 ideally we should be in the same scroll position than initially.
Anyway checking the CSSOM View spec there are a bunch of properties that mention unscaled values (like clientHeight or offsetHeight) while others don't (like scrollTop). Should we make them consistent? (Maybe there were some previous discussion on the topic and there's a reason why some properties use unscaled values while others don't).
Checking those properties on Firefox is not consistent either. For example in this WPT test initially we have:
scrollTop: 77
clientHeight: 100
offsetHeight: 110
When we change zoom to 1.2 then we get:
scrollTop: 64
clientHeight: 100
offsetHeight: 130
In Chromium (with that patch and the corresponding runtime flag) and WebKit they don't change.
WDYT?
|
|
||
Comment 4•5 months ago
|
||
offsetHeight should use unscaled values, but scrollTop and clientHeight already do. The question is whether the preserved scroll offset is scaled or unscaled, and I don't think one is better than the other.
|
|
||
Comment 5•5 months ago
|
||
I don't have a strong opinion in which one is better, and not sure if it's even worth to discuss at CSSWG level (I'll leave it to you if you want to open an issue about that inconsistency if we compare Chromium/WebKit and Firefox behaviors).
Anyway, I've made a PR for WPT that removes the assert in the intermediate state, as it's not key for the test. The test without such assert still fails in Chromium without the patch+flag. And it should pass in Firefox.
Description
•