Closed Bug 1203058 Opened 9 years ago Closed 9 years ago

Strip across the bottom of rendered pages

Categories

(Firefox for Android Graveyard :: Toolbar, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox42 unaffected, firefox43+ verified, firefox44+ verified, firefox45+ verified, b2g-v2.5 fixed, fennec43+)

VERIFIED FIXED
Firefox 45
Tracking Status
firefox42 --- unaffected
firefox43 + verified
firefox44 + verified
firefox45 + verified
b2g-v2.5 --- fixed
fennec 43+ ---

People

(Reporter: tech4pwd, Assigned: kats)

References

Details

(Keywords: regression)

Attachments

(3 files)

Attached image Screenshot_2015-09-09-10-09-35.png (deleted) —
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20150817085917

Steps to reproduce:

Seeing this on the tablet running 5.1.1
OS: Unspecified → Android
Hardware: Unspecified → ARM
I see this on my Galaxy S5.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
Can we reproduce and get a regression range?
Flags: needinfo?(kbrosnan)
Was working on bisecting a few days ago bug 1208163 is an annoyance on one device I can reproduce on.
(In reply to Michael Comella (:mcomella) from comment #1)
> I see this on my Galaxy S5.

Mike - Can you try to mozregression on your device?
Flags: needinfo?(michael.l.comella)
Galaxy S5 is the device that MozRegression is broken on.
(In reply to Kevin Brosnan [:kbrosnan] from comment #5)
> Galaxy S5 is the device that MozRegression is broken on.

All GS5 devices? Would it be worth trying anyway?
Mike - Let's fallback to manual bisecting! Can you try narrowing down the range a bit?
Are you guys still seeing this? Kats fixed an issue like this at one point before he left...
Flags: needinfo?(michael.l.comella) → needinfo?(pwd.mozilla)
Teodora, can you see if you can reproduce this and get a regression range?
Flags: needinfo?(teodora.vermesan)
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #8)
> Are you guys still seeing this? Kats fixed an issue like this at one point
> before he left...

I am indeed still seeing this.
Flags: needinfo?(pwd.mozilla)
I can't reproduce the issue on latest Nightly using Samsung S5 (Android 4.4.2), Nexus 7 (Android 5.1), Nexus 9 (Android 5.1.1)

Can you please tell me the device you reproduced the issue and also the steps to reproduce?
Flags: needinfo?(teodora.vermesan)
Flags: needinfo?(pwd.mozilla)
(In reply to Teodora Vermesan (:TeoVermesan) from comment #11)
> I can't reproduce the issue on latest Nightly using Samsung S5 (Android
> 4.4.2), Nexus 7 (Android 5.1), Nexus 9 (Android 5.1.1)
> 
> Can you please tell me the device you reproduced the issue and also the
> steps to reproduce?

Nvidia Shield Tablet (Android 5.1). While I'm seeing it less than before, I've still been seeing it.
Flags: needinfo?(pwd.mozilla)
This doesn't look like anything APZ would fix.
No longer depends on: 1206872
Assignee: nobody → milan
tracking-fennec: ? → 43+
So, this started showing up in nightly in 43 (based on comment 0.)  Does it still happen in nightly, or just in 43?  When it happens, does changing the orientation fix it?  Does switching to another application and back to Firefox fix it?  Does it always happen with an image like in the screenshot, or is it sometimes with text (if image, I wonder if it is related to bug 1194837 that was fixed in 44.)
Still happens
Scrolling fixes it, haven't checked orientation
I don't Know, see above
It happens on text heavier pages too
Assignee: milan → bugmail.mozilla
Component: General → Graphics, Panning and Zooming
I haven't yet found a device that can consistently reproduce this, but I can very intermittently see something like this on my Nexus 4 - it can happen if I'm on a page scrolled such that the dynamic toolbar is hidden, and then I click on a link to go to a new page. The new page can sometimes load with a strip at the bottom missing, corresponding to the height of the toolbar.

I added much logging throughout the code and traced this down to the setNextPaintSyncId call failing; the browser.js sets the paint sync id on the DOMWindowUtils but the widget on the DWU is null (because the page is being unloaded to load the next page, presumably) and so the sync id gets dropped. This results in the java state getting stuck in a "resize" (DynamicToolbarAnimator's mHeightDuringResize is non-null) and causes the visual problem. Panning after that will trigger a toolbar animation that clears the resize state, fixing the problem.

I have a patch to fix this, although I'm not yet sure if it's the same issue that everybody else is seeing. Nonetheless I can get the fix in and see if it helps.
Attached patch Patch (deleted) — Splinter Review
The key change here is using the domwindowutils of the top-level window rather than the selected tab's window. Even if the tab's window is being unloaded (and thus has a null widget) the top-level window should have a non-null widget reference. This should prevent the sync id from getting dropped.
Attachment #8689369 - Flags: review?(rbarker)
Attachment #8689369 - Flags: review?(rbarker) → review+
https://hg.mozilla.org/mozilla-central/rev/8050594771f3
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45
(In reply to Wes Kocher (:KWierso) from comment #23)
> https://hg.mozilla.org/mozilla-central/rev/8050594771f3

Why is this patch in FF 45? Why not 43 or 44?
It always lands on mozilla-central first before being considered for uplifts.
Paul, can you check tomorrow's nightly to see if this still happens? If it does I can make a try build with additional logging to track down what's going on. If it's fixed we can uplift this patch. Thanks!
Flags: needinfo?(pwd.mozilla)
Attached patch Additional logging if needed (deleted) — Splinter Review
Might as well stash my extra logging patch here so I don't lose it, this issue may crop up again later even if it is fixed for now.
Comment on attachment 8689369 [details] [diff] [review]
Patch

Approval Request Comment
[Feature/regressing bug #]: bug 1180295, which landed in 43
[User impact if declined]: sometimes there is a strip of unpainted content at the bottom of the screen which is the height of the URL bar. It looks pretty bad, but goes away once the user starts panning. This patch should fix at least some cases in which it occurs, although there may be other scenarios.
[Describe test coverage new/current, TreeHerder]: I don't have reliable STR so I was unable to definitively verify the fix, although I'm fairly confident it will fix at least one source of this problem, which I was seeing locally.
[Risks and why]: low risk. it's a small change and i can't see it making things any worse than they already are.
[String/UUID change made/needed]: none
Attachment #8689369 - Flags: approval-mozilla-beta?
Attachment #8689369 - Flags: approval-mozilla-aurora?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #26)
> Paul, can you check tomorrow's nightly to see if this still happens? If it
> does I can make a try build with additional logging to track down what's
> going on. If it's fixed we can uplift this patch. Thanks!

I've given it the usual checks and can confirm that this seems to be fixed. I'll keep an eye on it, but it seems you managed to track it down. Thanks for your hard work Kats.
Status: RESOLVED → VERIFIED
Flags: needinfo?(pwd.mozilla)
Comment on attachment 8689369 [details] [diff] [review]
Patch

Recent regression, has had some manual verification on nightly.
OK to uplift to aurora and beta.
Attachment #8689369 - Flags: approval-mozilla-beta?
Attachment #8689369 - Flags: approval-mozilla-beta+
Attachment #8689369 - Flags: approval-mozilla-aurora?
Attachment #8689369 - Flags: approval-mozilla-aurora+
Verified as fixed on all builds (45.0a1, 44.0a2 and 43.0b1)
This issue was tested on Sony Xperia Z2 tablet with Android 5.0.2 and Nexus 6 phone with Android 5.1.1.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: