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

RESOLVED FIXED in Firefox 52



Firefox for Android
a year ago
9 months ago


(Reporter: kats, Assigned: kats)


({regression, steps-wanted})

52 Branch
Firefox 52
regression, steps-wanted

Firefox Tracking Flags

(firefox49 unaffected, firefox50 unaffected, firefox51 unaffected, firefox52 verified)


MozReview Requests


Submitter Diff Changes Open Issues Last Updated
Error loading review requests:


(2 attachments)

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.
Summary: Layerview sometimes get stuck in a state where there is a perma-bar of white on the bottom of the screen → Fennec sometimes get stuck in a state where there is a perma-bar of white on the bottom of the screen

Comment 1

a year ago
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

No white bar at the bottom

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.
Flags: needinfo?(bugmail)
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.
Flags: needinfo?(bugmail)
I also haven't seen this issue again since I filed this bug, so maybe it went away?
status-firefox49: --- → unaffected
status-firefox50: --- → unaffected
status-firefox51: --- → ?
I haven't seen this again. Closing for now, will reopen if it comes back.
Last Resolved: a year ago
Resolution: --- → WORKSFORME
Saw this again today, on both Nightly and Aurora.
status-firefox51: ? → affected
Resolution: WORKSFORME → ---
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 [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
Blocks: 1296887
Assignee: nobody → bugmail
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
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 hidden (mozreview-request)
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.
status-firefox51: affected → unaffected

Comment 13

a year ago
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.

Attachment #8801484 - Flags: review?(rbarker) → review+

Comment 14

a year ago
Pushed by kgupta@mozilla.com:
Ensure we don't clear the paint sync id unless it has actually been sent to Java via SyncViewportInfo. r=rbarker

Comment 15

a year ago
Last Resolved: a year agoa year ago
status-firefox52: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52

Comment 16

9 months ago
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.
status-firefox52: fixed → verified


9 months ago
See Also: → bug 1336929
You need to log in before you can comment on or make changes to this bug.