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

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

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

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.

Comment 1

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

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.

Comment 2

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

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

Comment 3

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

Attachment: Check if the viewport is overridden before propagating an outerwindow resize to the innerwindow

Comment 4

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

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.

Comment 5

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

Try looks green, landing.

https://hg.mozilla.org/integration/mozilla-inbound/rev/5c772b35c40d

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5c772b35c40d

Comment 7

[Cristina Madaras, QA [:CristinaM]]

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