Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Strip across the bottom of rendered pages

VERIFIED FIXED in Firefox 43, Firefox OS v2.5

Status

()

Firefox for Android
Graphics, Panning and Zooming
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: Paul [pwd], Assigned: kats)

Tracking

({regression})

Trunk
Firefox 45
ARM
Android
regression
Points:
---

Firefox Tracking Flags

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

Details

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Created attachment 8658620 [details]
Screenshot_2015-09-09-10-09-35.png

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
(Reporter)

Updated

2 years ago
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?
Keywords: regressionwindow-wanted
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)

Comment 9

2 years ago
Teodora, can you see if you can reproduce this and get a regression range?
Flags: needinfo?(teodora.vermesan)
(Reporter)

Comment 10

2 years ago
(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)
(Reporter)

Comment 12

2 years ago
(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)
Waiting to see how APZ affects this – bug 1206872.
Depends on: 1206872
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.)
(Reporter)

Comment 16

2 years ago
Still happens
Scrolling fixes it, haven't checked orientation
I don't Know, see above
It happens on text heavier pages too
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=00d7cf36408654e5838650cd056d60a09a3dd4b0&tochange=2b213c98f8a8d85a03aa64aa502abd88048239ce
Blocks: 1180295
status-firefox42: --- → unaffected
status-firefox43: --- → affected
status-firefox44: --- → affected
status-firefox45: --- → affected
tracking-firefox43: --- → ?
tracking-firefox44: --- → ?
tracking-firefox45: --- → ?
Flags: needinfo?(kbrosnan)
Keywords: regressionwindow-wanted → regression
Duplicate of this bug: 1224891
Assignee: milan → bugmail.mozilla
Component: General → Graphics, Panning and Zooming
Tracking since this is a recent regression.
tracking-firefox43: ? → +
tracking-firefox44: ? → +
tracking-firefox45: ? → +
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.
Created attachment 8689369 [details] [diff] [review]
Patch

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+

Comment 22

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/8050594771f3

Comment 23

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/8050594771f3
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox45: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45

Comment 24

2 years ago
(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)
Created attachment 8689904 [details] [diff] [review]
Additional logging if needed

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?
(Reporter)

Comment 29

2 years ago
(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+
https://hg.mozilla.org/releases/mozilla-aurora/rev/3669fc2d3b4f
https://hg.mozilla.org/releases/mozilla-beta/rev/659118226cbd
status-firefox43: affected → fixed
status-firefox44: affected → fixed
https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/3669fc2d3b4f
status-b2g-v2.5: --- → fixed

Comment 33

2 years ago
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.
status-firefox43: fixed → verified
status-firefox44: fixed → verified
status-firefox45: fixed → verified
You need to log in before you can comment on or make changes to this bug.