In some cases the viewport used to render a page changes to something incorrect

VERIFIED FIXED in Firefox 37

Status

()

VERIFIED FIXED
4 years ago
a year ago

People

(Reporter: kats, Assigned: kats)

Tracking

unspecified
Firefox 37
All
Android
Points:
---

Firefox Tracking Flags

(firefox37 verified, firefox38 verified, fennec37+)

Details

(URL)

Attachments

(1 attachment)

On my Nexus 4 running nightly, I see a bug where a page I use regularly sometimes gets re-rendered with the wrong meta-viewport after I switch tabs. I've seen this for a while now but never bothered to file a bug, but now I have reproducible STR.

STR:
1. Start Fennec, and open a tab to the URL provided in this bug's URL field. Observe how at the top of the page there are some boxes over on the right side.
2. Open a new tab and go to mxr.mozilla.org/mozilla-central and put focus in the search field there. (I think the key in this step is just that the virtual keyboard comes up, and any text field should be fine)
3. Switch back to the first tab.

Actual results:
Observe that all the boxes are now in a single column. This is a result of the @media (max-width:800px) style rule taking effect.

Expected results:
The page rendering should not have changed, because the max-width media rules should be the same as on the first page load.

Bonus bug: scroll all the way down to the bottom of the page now (zoomed out as much as possible). The bottom of the page renders in low-res. This seems to be reliably reproducible for me on this specific page, I'm guessing it is related to the height of the page which is a function of the specific contents here.
Also, switching to another app and then switching back to Fennec will make the page re-render as expected. You can use this to continually reproduce the bug.

Updated

4 years ago
tracking-fennec: --- → ?
Based a quick investigation I think there might be multiple bugs here, and fixing the first one will likely obscure the rest. I'll try to spin off other bugs as I uncover stuff, but I'll start with the first thing that I see going wrong, which is the @media (max-width:800px) rule getting triggered.

It looks like the max-width property of media features is evaluated using the nsPresContext->GetVisibleArea [1] so I stuck a breakpoint at nsPresContext::SetVisibleArea to see why it ends up with a value of < 800px when it shouldn't really. When the keyboard comes up what I see happening is the code at [2] running. This does 2 things; the first is resize the fennec nsWindow [3] and the second is trigger a recalculation of the CSS viewport [4]. These two things are intended to correspond to updating the outer window dimensions and the inner window dimensions, respectively.

So this seems to happen more or less as expected. However, there is one hitch: when we resize the outer window, I think it queues up a delayed resize on the background tab. When tab is drawn for the next time (which I think happens when I open the tab switcher and the thumbnail gets painted), that delayed resize gets flushed (in nsViewManager::FlushDelayedResize) and it explicitly calls nsPresContext::SetVisibleArea [5] without checking to see if the viewport is overridden. This effectively forces the outer window dimensions onto the inner window, disregarding the fact that they can be different when dealing with meta viewpor tags. This leaves the nsPresContext::mVisibleArea with a width of < 800px which causes the media query to trigger.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/style/nsMediaFeatures.cpp?rev=aaf664c3735f#67
[2] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/GeckoLayerClient.java?rev=1f9b1f477588#264
[3] http://mxr.mozilla.org/mozilla-central/source/widget/android/nsWindow.cpp?rev=bf9c0ad8d4bb#964
[4] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=8e516e029c8e#6251
[5] http://mxr.mozilla.org/mozilla-central/source/view/nsViewManager.cpp?rev=a6db8f54f5aa#232
Created attachment 8547207 [details] [diff] [review]
Check if the viewport is overridden before propagating an outerwindow resize to the innerwindow
Attachment #8547207 - Flags: review?(dbaron)
Attachment #8547207 - Flags: review?(dbaron) → review+
I spun off bug 1120244 for another issue I found while debugging this. I couldn't find anything else. The bad viewport is the thing responsible for the bluriness in this case, because the displayport base rect is based on the viewport, and if that's too small then the high-res painted area ends up too small and you end up with visible bluriness. The patch on this bug seems to address that completely as far as I can tell. Waiting on the try run at https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=32c80a8fcbdb before landing.
https://hg.mozilla.org/mozilla-central/rev/5c772b35c40d
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 37
tracking-fennec: ? → 37+
Verified as fixed in Firefox for Android 37.0a2 (2015-01-16) and Firefox for Android 38.0a1 (2015-01-16);
Device: Samsung Galaxy S4 (Android 4.4.2).
Status: RESOLVED → VERIFIED
status-firefox37: --- → verified
status-firefox38: --- → verified
You need to log in before you can comment on or make changes to this bug.