If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

White space displayed at the bottom of the page after maximize/restore the browser

NEW
Assigned to

Status

()

Firefox
Developer Tools: Inspector
P3
normal
7 months ago
8 days ago

People

(Reporter: pauly, Assigned: bradwerth)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(firefox51 unaffected, firefox52 unaffected, firefox53 fix-optional, firefox54 fix-optional)

Details

(Reporter)

Description

7 months ago
[Affected versions]:
- 54.0a1 (2017-02-27)

[Affected platforms]:
- all

[Steps to reproduce]:
1. Maximize Firefox
2. Open http://labs.jensimmons.com/examples/grid-content-1.html
3. Open the Inspector
4. Click on <main> and activate the Grid Highlighter
5. Restore browser size and scroll the page down

[Expected result]:
- Grid still active
- Page should be displayed properly

[Actual result]:
- Grid no longer active
- White space displayed at the bottom of the page

[Regression range]:
- TBD, doesn't reproduce on 53.0a2 (2017-02-27)
(Reporter)

Comment 1

7 months ago
Screencast: https://www.screencast.com/t/dssODIqs

Comment 2

7 months ago
Regression window(White space displayed at the bottom of the page):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2ae8554e0989e12e9ef5755a4171841b02df7f11&tochange=07de05d8060cb97df8df4aaf371b7f23da4b46cb

Regressed by:
07de05d8060c	Matteo Ferretti — Bug 1312103 - Avoid scrolling latency on highlighters given by APZ; r=pbro

The white space problem also happens when doing Find in page.

Steps to Reproduce:
1. Maximize browser
2. Open http://labs.jensimmons.com/examples/grid-content-1.html
3. Ctrl+F to open Find toolbar and type "jazz" (without " marks)
4. Restore browser size and scroll the page down

Actual result:
 White space displayed at the bottom of the page
Blocks: 1312103
No longer blocks: 1181227, 1333358, 1333706
Flags: needinfo?(zer0)
This is unfortunate a well-known bug but I don't think it was reported yet, so thanks to filed this!

The issue happens because the highlighters are using JS to calculate the whole document dimensions, in order to overlay it completely. However, since the anonymous content – where we put the overlays – are considered part of the document, they're also used to calculate the document's dimensions: it's a kind of "inception" thingy.

Another STR to check easily the problem:
1. Open any page
2. Ctrl+F / Cmd+F to open  Find toolbar, type any string can be found in the page
3. Once the string is found, Ctrl+- / Cmd+- to zoom out (do that a couple of times or more to have a bigger result)
4. Ctrl+0 / Cmd+0 to restore the zoom

Actual result:
 The document now bigger than it was original; see the scrollbars.

What's happening:
 As said above, JS is not able to resize the overlay in the anonymous content *before* the browser reset the zoom, therefore the document's size are calculated considering the dimension of the document at that stage – that are much bigger since the zoom out.

How to solve this:
 Assuming we want to have an element the cover the entire document's dimensions, I can't imaging anything that we have currently in CSS or JS that can mitigate this problem. We probably need something on platform side to solve this.

Possible solutions (all of them needs something on platform side):
 1. Having some custom -moz CSS property / value that makes an element covers the entire document – not only the viewport, as width / height 100% does –, and at the same time makes the element where is applied be excluded by the document's size calculation. I think that the XUL stack had something similar. That would be the ideal solution since we don't have to recalculate manually in JS every time the document's dimensions, and it can slow down a lot; but I'm not sure how doable can be on platform side, if it's desirable, neither if there is any CSS specs for something similar.

 2. Having a CSS / HTML property that flag an element to be excluded by the document's size calculation. In this case we still need to calculate everything, but at least we fix the issue described in this bug. That should be more doable, I mentioned that to dholbert during the All Hands.
Flags: needinfo?(zer0)
Daniel, I'm needinfo'ing you since we have talk about that during the last All Hands, see comment 3.
Thanks!
Flags: needinfo?(dholbert)
Inspector bug triage (filter on CLIMBING SHOES).
Priority: -- → P3
(Reporter)

Comment 6

6 months ago
since bug 1312103 landed in Fx 53
status-firefox53: unaffected → affected

Updated

6 months ago
Keywords: regressionwindow-wanted

Updated

6 months ago
status-firefox53: affected → fix-optional
status-firefox54: affected → fix-optional
Duplicate of this bug: 1376764
(Assignee)

Updated

12 days ago
Assignee: nobody → bwerth
Hi Brad, since you're taking this I'm clearing the needinfo flag.
Flags: needinfo?(dholbert)
If you need to chat about this let me know! Also, if you have other solution in mind.
You need to log in before you can comment on or make changes to this bug.