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)
Tracking
(firefox42 unaffected, firefox43+ verified, firefox44+ verified, firefox45+ verified, b2g-v2.5 fixed, fennec43+)
VERIFIED
FIXED
Firefox 45
People
(Reporter: tech4pwd, Assigned: kats)
References
Details
(Keywords: regression)
Attachments
(3 files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
rbarker
:
review+
lizzard
:
approval-mozilla-aurora+
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•9 years ago
|
OS: Unspecified → Android
Hardware: Unspecified → ARM
Comment 1•9 years ago
|
||
I see this on my Galaxy S5.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
Comment 2•9 years ago
|
||
Can we reproduce and get a regression range?
Keywords: regressionwindow-wanted
Updated•9 years ago
|
Flags: needinfo?(kbrosnan)
Comment 3•9 years ago
|
||
Was working on bisecting a few days ago bug 1208163 is an annoyance on one device I can reproduce on.
Comment 4•9 years ago
|
||
(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)
Comment 5•9 years ago
|
||
Galaxy S5 is the device that MozRegression is broken on.
Comment 6•9 years ago
|
||
(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?
Comment 7•9 years ago
|
||
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•9 years ago
|
||
Teodora, can you see if you can reproduce this and get a regression range?
Flags: needinfo?(teodora.vermesan)
Reporter | ||
Comment 10•9 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)
Comment 11•9 years ago
|
||
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)
Updated•9 years ago
|
Flags: needinfo?(pwd.mozilla)
Reporter | ||
Comment 12•9 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)
Assignee | ||
Comment 14•9 years ago
|
||
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•9 years ago
|
||
Still happens
Scrolling fixes it, haven't checked orientation
I don't Know, see above
It happens on text heavier pages too
Comment 17•9 years ago
|
||
Blocks: dynamic-toolbar-2
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
Updated•9 years ago
|
Assignee: milan → bugmail.mozilla
Component: General → Graphics, Panning and Zooming
Tracking since this is a recent regression.
Assignee | ||
Comment 20•9 years ago
|
||
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.
Assignee | ||
Comment 21•9 years ago
|
||
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)
Updated•9 years ago
|
Attachment #8689369 -
Flags: review?(rbarker) → review+
Comment 22•9 years ago
|
||
Comment 23•9 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45
Comment 24•9 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?
Assignee | ||
Comment 25•9 years ago
|
||
It always lands on mozilla-central first before being considered for uplifts.
Assignee | ||
Comment 26•9 years ago
|
||
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)
Assignee | ||
Comment 27•9 years ago
|
||
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.
Assignee | ||
Comment 28•9 years ago
|
||
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•9 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+
Assignee | ||
Comment 31•9 years ago
|
||
Comment 32•9 years ago
|
||
bugherder uplift |
status-b2g-v2.5:
--- → fixed
Comment 33•9 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.
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•