|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
In the last few days I've noticed that sometimes Fennec gets stuck in a state where there's a white bar (size of the dynamic toolbar) at the bottom of the screen. It's almost certainly a dynamic toolbar bug and possibly a regression from bug 1296887 which was the last change made to it. I'm going to run an instrumented logging build to see if it hits that codepath the next time I see this problem. It's pretty intermittent and I don't have STR. However once it happens, showing/hiding the toolbar or even switching tabs doesn't clear it. Not sure about rotation, I'll try that. It does randomly go away on its own at some point.
Created attachment 8797066 [details] Bottom white bar.png Hi Kartikaya, I attached a screenshot with a youtube video that has a white bottom bar. Is this the same issue that you are seeing? If so the STR are: 1. Go to youtube -> play any video -> tap fullscreen Expected: No white bar at the bottom Actual: There is a white bar at the bottom of the video as in attachment(portrait or landscape - it's the same result) Note: After you switch device orientation the white bar disappears. So you have to leave fullscreen and enter again.
It sounds different from the issue I was seeing. In particular on rotation with the issue I was seeing things got worse and there was only a small strip of visible content near the top whereas in your case it fixes the problem. Also I cannot reproduce what you are seeing following your STR.
I also haven't seen this issue again since I filed this bug, so maybe it went away?
I haven't seen this again. Closing for now, will reopen if it comes back.
Saw this again today, on both Nightly and Aurora.
It seems to happen more often when opening/closing tabs
I caught this today with logging enabled, and it does appear to be a regression from bug 1296887. I can sort of reproduce it using these STR: - Go to news.ycombinator.com - Scroll down so that the URL bar hides - Click on a link to an article. This will re-show the toolbar. In my case the link was to http://www.billthelizard.com/2008/12/books-programmers-dont-really-read.html which is a pretty simple page - Wait for the page to finish loading, then scroll down on that page to hide the toolbar - Hit back to go back to the main HN page - Observe white bar on the bottom of the screen. It looks like we get stuck going down the path at  so isResizing() is probably getting stuck to true. Not sure why but I think it's probably better to back out bug 1296887 for now - this bug is rather worse than the fix.  http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/mobile/android/geckoview/src/main/java/org/mozilla/gecko/gfx/DynamicToolbarAnimator.java#241
I reproduced this with enough logging to discover that the mPaintSyncId is getting cleared at  without getting sent to the Java code, because we're going down the mIsFirstPaint codepath at . We should probably move the line to reset mPaintSyncId up inside the else block.  http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/gfx/layers/composite/AsyncCompositionManager.cpp#1030  http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/gfx/layers/composite/AsyncCompositionManager.cpp#1008
I verified that moving up mPaintSyncId seems to fix this bug. However I'm not 100% confident in this fix, so I propose to land it on Nightly 52 and let it ride the trains, but also back out the fix from bug 1296887 from aurora 51. That way Aurora 51 should behave the same as Beta 50 and previous shipped releases, but 52 will have the extra fixes and no additional regressions.
Also technically this is a bug in the dynamic toolbar implementation in bug 1180295, it was just made a lot worse by bug 1296887.
51 should now be unaffected as I backed out the regressing bug on that branch.
Comment on attachment 8801484 [details] Bug 1305969 - Ensure we don't clear the paint sync id unless it has actually been sent to Java via SyncViewportInfo. https://reviewboard.mozilla.org/r/86240/#review85122
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/e109b8c04871 Ensure we don't clear the paint sync id unless it has actually been sent to Java via SyncViewportInfo. r=rbarker
Verified as fixed on 52.0b2 on a Samsung Galaxy Tab Active (Android 5.1.1). Following STR @comment 7 this issue could not be reproduced, not even in combination with rotation during load.