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

Status: RESOLVED WORKSFORME

(DevTools :: Inspector, defect, P3)

Description

[Paul Silaghi, QA [:pauly]]

[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)

Comment 1

[Paul Silaghi, QA [:pauly]]

Screencast: https://www.screencast.com/t/dssODIqs

Comment 2

[Alice0775 White]

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

Comment 3

[Matteo Ferretti [:zer0] [:matteo]]

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.

Comment 4

[Matteo Ferretti [:zer0] [:matteo]]

Daniel, I'm needinfo'ing you since we have talk about that during the last All Hands, see comment 3.
Thanks!

Comment 5

[Patrick Brosset <:pbro>]

Inspector bug triage (filter on CLIMBING SHOES).

Comment 6

[Paul Silaghi, QA [:pauly]]

since bug 1312103 landed in Fx 53

Comment 8

[Matteo Ferretti [:zer0] [:matteo]]

Hi Brad, since you're taking this I'm clearing the needinfo flag.

Comment 9

[Matteo Ferretti [:zer0] [:matteo]]

If you need to chat about this let me know! Also, if you have other solution in mind.

Comment 10

[Brad Werth [:bradwerth]]

This appears to have been fixed at some point.