739289 - Far too much space at bottom of page with position fixed elements when zoomed in

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Martijn Wargers (dead)]

Attachment: Screenshot bottom of page zoomed out

I found this while investigating bug 739053.


When zooming in, there is far too much 'free space' at the bottom, which you don't get while zoomed in.
See screenshots.

This is with the latest trunk build on the Samsung Galaxy SII.

Comment 1

[Martijn Wargers (dead)]

Attachment: Screenshot bottom of page zoomed in

This is the screenshot that shows the bug in question.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

There is a position:fixed element on the page that is screwing with us. When you zoom in, it gets positioned below the bottom of the viewport, and somehow causes the page size to increase (presumably it affects the mContentSize in the compositor). This is tricky, I don't know how we're supposed to be dealing with position:fixed elements.

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

also adding a dependency to bug 732016 because it looks vaguely related.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

please comment out this line [https://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1560] and retest. If that fixes it, then this is a dupe of bug 732016.

Comment 5

[Martijn Wargers (dead)]

Unfortunately, I can't reproduce this anymore on the url in question, I even tried this on a build at the time I filed this bug.
I guess something in the page has changed.

I tried to get a testcase based on comment 3, but I haven't been able to get position:fixed elements to influence the size of the viewport at all.

Perhaps there is some relation to bug 656036 here? Perhaps any of the devs know how to reproduce this, still?

Comment 6

[Aaron Train [:aaronmt]]

Built a debug with clamp scroll position commented out and it reintroduced this issue; as per comment #4. Tested on Nightly proper and I could not reproduce.

Comment 7

[Martijn Wargers (dead)]

(In reply to Aaron Train [:aaronmt] from comment #6)
Comment 4 is saying that commenting out that line would fix it, not reintroduce it.
So is this still a dupe?
Aaron, could you perhaps make a minimized testcase out of the issue?

Comment 8

[Kartikaya Gupta (email:[e-mail])]

I still believe that the original problem on this page was due to position:fixed elements and is unrelated to bug 732016. If it is no longer happening that's fine, we can leave this bug as WFM. There's an endless supply of pages on which this will be reproducible (and there are already bugs open for some of them) so we'll fix it eventually.