Use layout viewport size (i.e. not ICB, the size expanded by minimums-scale) for window.innerHeight
Categories
(Core :: Layout, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox145 | --- | fixed |
People
(Reporter: bradwerth, Assigned: hiro)
References
(Blocks 2 open bugs)
Details
(Keywords: webcompat:platform-bug)
Attachments
(9 files, 1 obsolete file)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
630 bytes,
text/html
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Bug 1514429 disabled this test. The comparisons between visualViewport, layout viewport (window.innerHeight), documentElement.scrollHeight, and documentElement.getBoundingClientRect all need to be audited to see if we still have some incorrect behavior.
| Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
| Assignee | ||
Comment 1•6 years ago
|
||
I've realized the reason why the test fails. That's because we return nsPresContext::mVisibleArea in nsGlobalWindowOuter::GetInnerSize but apparently the layout viewport of the test case is expanded by 'minimum-scale=0.5' in meta viewport tag so we need to return the layout viewport instead of nsPresContext::mVisibleArea.
I did push a try with returning the layout viewport from the function, but unfortunately it causes a bunch of test failures. Probably I am missing something.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5e02d9dc6f7e5c46aaf7fbe48ca52d57a472df2f&selectedJob=278204951
| Assignee | ||
Updated•6 years ago
|
Comment 2•6 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)
I've realized the reason why the test fails. That's because we return nsPresContext::mVisibleArea in nsGlobalWindowOuter::GetInnerSize but apparently the layout viewport of the test case is expanded by 'minimum-scale=0.5' in meta viewport tag so we need to return the layout viewport instead of nsPresContext::mVisibleArea.
Ah, good point! I forgot about this when reviewing bug 1514429...
I did push a try with returning the layout viewport from the function, but unfortunately it causes a bunch of test failures. Probably I am missing something.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5e02d9dc6f7e5c46aaf7fbe48ca52d57a472df2f&selectedJob=278204951
Possibly there are internal uses of innerWidth/Height which are expecting the ICB size and not the layout viewport size, which may need to be modified to obtain the ICB size some other way, like document.scrollingElement.clientWidth/Height.
| Assignee | ||
Comment 3•6 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #2)
I did push a try with returning the layout viewport from the function, but unfortunately it causes a bunch of test failures. Probably I am missing something.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5e02d9dc6f7e5c46aaf7fbe48ca52d57a472df2f&selectedJob=278204951Possibly there are internal uses of
innerWidth/Heightwhich are expecting the ICB size and not the layout viewport size, which may need to be modified to obtain the ICB size some other way, likedocument.scrollingElement.clientWidth/Height.
There probably are. A big mistake I missed is that PresShell::GetViewportSize() is only meaningful on root scrollable shell, presumably the function should return nsPresContext::mVisibleArea for fallback cases.
I did push another try now. We can probably see more reasonable results (failures) there.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=db6f6b06ff279b558a68b7bac52ccfea66f17e53
| Assignee | ||
Comment 4•6 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
I did push another try now. We can probably see more reasonable results (failures) there.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=db6f6b06ff279b558a68b7bac52ccfea66f17e53
The change in this try was wrong again. It clobbers the layout viewport size...
Here is a try with more reasonable change (that I believe)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6126be183576a9cb9ecddb802927d39fa0a9684b
Still I am probably missing something. I will revisit this issue after bug 1523541.
| Assignee | ||
Updated•6 years ago
|
| Assignee | ||
Comment 5•6 years ago
|
||
A big thing I missed is that we just need to use the layout viewport only if it's in the root content document.
Here is a new try, the result looks reasonable, most of failed tests need to be addressed by this window.innerHeight change. One exception is test_innerWidthHeight_script.html, we probably need to fix bug 1595962 first.
| Assignee | ||
Comment 6•6 years ago
|
||
FWIW here is a reasonable try result;
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f77ac89e97e267972e03fc3560ab5d04ed289587
| Assignee | ||
Updated•5 years ago
|
Updated•3 years ago
|
Comment 7•1 year ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #5)
Here is a new try, the result looks reasonable, most of failed tests need to be addressed by this window.innerHeight change. One exception is test_innerWidthHeight_script.html, we probably need to fix bug 1595962 first.
Hiro, do you remember why fixing this test failure requires innerWidth/innerHeight to be non-writable? I can't find a test named test_innerWidthHeight_script.html in today's mozilla-central, so I wonder whether we can try this again without fixing the dependencies of bug 1595962.
| Assignee | ||
Comment 8•1 year ago
|
||
Though I wasn't aware of the fact that the test file has been removed in bug 1837953, the test file is actually a test case ensure those attributes are writable.
So yeah, you are right, now it's time to fix this bug.
Comment 9•1 year ago
|
||
Raising priority and marking as webcompat:platform-bug due to this causing bug 1944725.
| Assignee | ||
Comment 10•9 months ago
|
||
The document in question gets scaled down on mobile so with the spec
compliant window.innerHeight (comming in the next commit), the value
would be much bigger than it's supposed to be.
Updated•9 months ago
|
| Assignee | ||
Comment 11•9 months ago
|
||
| Assignee | ||
Comment 12•9 months ago
|
||
| Assignee | ||
Comment 13•9 months ago
|
||
Updated•9 months ago
|
| Assignee | ||
Comment 14•9 months ago
|
||
For future reference, I used this test to tell whether Chrome flushes layout on window.innerWidth call. Actually Chrome flushes layout.
| Assignee | ||
Comment 15•9 months ago
|
||
And specify <!DOCTYPE html> in relevant test cases to use standars mode.
The proper window.inner{Width,Height} values depend on the initial zoom
value, rather documentElement.client{Width,Height} are independent from
the zoom value.
Note that documentElement.clientHeight on quirks mode is diffrent from
the one on standards mode. E.g. if the document is zoomed by 0.5x, then
documentElement.clientHeight on quirks mode is twice the value of the
one on standards mode. I've confirmed the behavior is same in Chrome's
RDM.
| Assignee | ||
Comment 16•9 months ago
|
||
And specify <!DOCTYPE html> in scroll.html.
| Assignee | ||
Comment 17•9 months ago
|
||
There are some wpts had no meta viewport tag and have at least either
one of window.innerWidth or window.innerHeight call. We hadn't flushed
any pending layout changes on either window.innerWidth or
window.innerHeight call, but with flushing layout these tests start
failing since the rendering results are not what each test is supposed
to be, i.e. the content is scaled down. In other words these tests had
been accidentally passing on mobile environments due to missing meta
viewport tags. With the proper meta viewport tag, some wpts start
passing on mobile environments.
| Assignee | ||
Comment 18•9 months ago
|
||
The test enlarges the target element width to window.innerWidth+100px,
thus without minimum-scale=1 the document gets scaled down further to
fit the enlarged element into the view. Thus the element becomes fully
visible, is not partially visible what the the test supposed to be.
| Assignee | ||
Comment 19•9 months ago
|
||
Similar to the previous change but for
test_element_in_view_center_point_partly_visible using
get_actions_origin_page().
| Assignee | ||
Updated•9 months ago
|
Comment 20•9 months ago
|
||
Comment 21•9 months ago
|
||
Comment 22•9 months ago
|
||
Backed out for causing mochitest failures on test_group_double_tap_zoom-2.html
| Assignee | ||
Comment 24•9 months ago
|
||
Dumped window.innerHeight and document.documentElement.clientHeight on a mac in a try run. The values are;
window.innerHeight: 864
document.documentElement.clientHeight: 849
It looks to me that our Mac on CIs enables "showing always scrollbars options".
With this small difference helper_doubletap_zoom_hscrollbar2.html fails on Mac.
I did add html {scrollbar-width: none} in D262531 to avoid this difference.
Comment 26•9 months ago
|
||
Comment 27•9 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/3245f080dd68
https://hg.mozilla.org/mozilla-central/rev/d884c11dedf1
https://hg.mozilla.org/mozilla-central/rev/936685abe38e
https://hg.mozilla.org/mozilla-central/rev/06e4e355e044
https://hg.mozilla.org/mozilla-central/rev/6fb777dd5dde
https://hg.mozilla.org/mozilla-central/rev/8677fea330b9
https://hg.mozilla.org/mozilla-central/rev/d7c3586418d7
https://hg.mozilla.org/mozilla-central/rev/253563bc6f5a
Updated•8 months ago
|
Updated•5 months ago
|
Description
•