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

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

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

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.

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

Inspector bug triage (filter on CLIMBING SHOES).

since bug 1312103 landed in Fx 53

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

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