1305969 - Fennec sometimes get stuck in a state where there is a perma-bar of white on the bottom of the screen

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect, P2)

Description

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

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.

Comment 1

[Alex Caziuc]

Attachment: 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.

Comment 2

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

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.

Comment 3

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

I also haven't seen this issue again since I filed this bug, so maybe it went away?

Comment 4

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

I haven't seen this again. Closing for now, will reopen if it comes back.

Comment 5

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

Saw this again today, on both Nightly and Aurora.

Comment 6

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

It seems to happen more often when opening/closing tabs

Comment 7

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

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 [1] 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.

[1] http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/mobile/android/geckoview/src/main/java/org/mozilla/gecko/gfx/DynamicToolbarAnimator.java#241

Comment 8

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

I reproduced this with enough logging to discover that the mPaintSyncId is getting cleared at [1] without getting sent to the Java code, because we're going down the mIsFirstPaint codepath at [2]. We should probably move the line to reset mPaintSyncId up inside the else block.

[1] http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/gfx/layers/composite/AsyncCompositionManager.cpp#1030
[2] http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/gfx/layers/composite/AsyncCompositionManager.cpp#1008

Comment 9

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

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.

Comment 10

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

Attachment: Bug 1305969 - Ensure we don't clear the paint sync id unless it has actually been sent to Java via SyncViewportInfo.

Review commit: https://reviewboard.mozilla.org/r/86240/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/86240/

Comment 11

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

Also technically this is a bug in the dynamic toolbar implementation in bug 1180295, it was just made a lot worse by bug 1296887.

Comment 12

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

51 should now be unaffected as I backed out the regressing bug on that branch.

Comment 13

[Randall Barker [:rbarker]]

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

Comment 14

[Pulsebot]

Pushed by [e-mail]:
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

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e109b8c04871

Comment 16

[u549602]

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.

Comment 17

[Chris Peterson [:cpeterson]]

Removing steps-wanted keyword because this bug has been resolved.