Closed
Bug 1086683
Opened 10 years ago
Closed 10 years ago
Blurry/missing section of page at the bottom
Categories
(Firefox for Android Graveyard :: Toolbar, defect)
Tracking
(firefox33 wontfix, firefox34+ wontfix, firefox35+ verified, firefox36+ verified, fennec34+)
People
(Reporter: snorp, Assigned: tnikkel)
References
()
Details
(Keywords: regression)
Attachments
(5 files, 4 obsolete files)
158.18 KB,
image/png
|
Details | |
80.48 KB,
image/png
|
Details | |
352.93 KB,
text/plain
|
Details | |
2.42 KB,
patch
|
botond
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
374.89 KB,
image/png
|
Details |
I have a problem on tablet with the bottom portion of the page being blurry. It is 100% reproducible on http://people.mozilla.org/~atrain/mobile/tests/media.html If I turn off low precision buffers (via layers.low-precision-buffer=off), that section of the page is just totally missing. The area looks suspiciously like the same height as the toolbar, so I would say there is some interaction gone bad there.
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
Kats: any ideas?
tracking-fennec: --- → ?
Flags: needinfo?(bugmail.mozilla)
Comment 3•10 years ago
|
||
I think somebody filed a very similar bug earlier but I can't find it now. Is this on a Nexus 7 or some other device?
Flags: needinfo?(bugmail.mozilla)
Comment 4•10 years ago
|
||
You are thinking of bug 1058272.
Reporter | ||
Comment 5•10 years ago
|
||
Yeah, this blurriness never goes away, so it's a little different.
Reporter | ||
Comment 6•10 years ago
|
||
This is busted on 32 too, so if it's a regression then it's pretty old.
Reporter | ||
Comment 7•10 years ago
|
||
Err, I mean 33.
Comment 8•10 years ago
|
||
Actually I was thinking of https://bug1043961.bugzilla.mozilla.org/attachment.cgi?id=8475112 but I guess that's unrelated.
Reporter | ||
Updated•10 years ago
|
status-firefox33:
--- → fixed
status-firefox34:
--- → affected
status-firefox35:
--- → affected
status-firefox36:
--- → affected
Reporter | ||
Updated•10 years ago
|
Hello guys, I have this issue on my device too. It's happening on every small web-page. Device: DragonBoard Firefox version: 34.0b2 Hopefully you can fix it.
Comment 10•10 years ago
|
||
Hi, We are also facing this issue. Bottom of some pages is blurred. Used Firefox version 33.0a1 on DVT board. Steps to reproduce: 1. Open any small web-page (www.guimp.com, www.bertricesmall.net) 2. Scroll to the bottom
Comment 11•10 years ago
|
||
Any updates on a fix or workaround for this issue? Seems to affect a great deal of the pages I am opening in the browser. I am using build 33 as well.
Reporter | ||
Comment 13•10 years ago
|
||
Kats, maybe you can take a quick look at this since it seems vaguely viewport related?
Flags: needinfo?(bugmail.mozilla)
Comment 14•10 years ago
|
||
I can't reproduce this. If you can repro consistently, can you check to see if it re-regressed sometime after bug 1043961 was fixed? Based on the time-distribution of people complaining about this it feels like this got broken again recently and perhaps the breaking change was uplifted everywhere.
Flags: needinfo?(bugmail.mozilla) → needinfo?(snorp)
Comment 15•10 years ago
|
||
It reproduced just on devices with full HD resolution(1920×1080). I checked on two different devices Nexus 10 and dragonboard.
Comment 16•10 years ago
|
||
For those that can reproduce, any chance of getting a regression range?
Assignee: milan → nobody
Keywords: regressionwindow-wanted
Reporter | ||
Comment 17•10 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14) > I can't reproduce this. If you can repro consistently, can you check to see > if it re-regressed sometime after bug 1043961 was fixed? Based on the > time-distribution of people complaining about this it feels like this got > broken again recently and perhaps the breaking change was uplifted > everywhere. I tried the nightly from 07/11 and it reproduces there.
Flags: needinfo?(snorp)
Reporter | ||
Comment 18•10 years ago
|
||
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #17) > (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14) > > I can't reproduce this. If you can repro consistently, can you check to see > > if it re-regressed sometime after bug 1043961 was fixed? Based on the > > time-distribution of people complaining about this it feels like this got > > broken again recently and perhaps the breaking change was uplifted > > everywhere. > > I tried the nightly from 07/11 and it reproduces there. (to be clear, that is before bug 1043961 landed, so I don't think it regressed this)
Reporter | ||
Comment 19•10 years ago
|
||
Initially this seemed like it could be related to the scrolling header, because the blurred part was about the same height. It reproduces here with that disabled, though, so maybe it's not related.
Reporter | ||
Comment 20•10 years ago
|
||
Some more information: it only reproduces when in landscape orientation on the tablet. Rotating to portrait makes things look fine, rotating back again and it's blurry. It does not reproduce on my phone in any orientation even though it has a 1920x1080 screen. The tablet I'm using is 1920x1200 (Sony Z2)
Updated•10 years ago
|
Assignee: nobody → snorp
tracking-fennec: ? → 34+
Reporter | ||
Comment 21•10 years ago
|
||
Comment 22•10 years ago
|
||
Can you also turn on layers.dump? It's a little hard to read this log without the layer tree information. Also logcat -v time would be good as it helps isolate a single paint cycle. Thanks.
Flags: needinfo?(snorp)
Reporter | ||
Comment 23•10 years ago
|
||
Attachment #8510490 -
Attachment is obsolete: true
Flags: needinfo?(snorp)
Comment 24•10 years ago
|
||
I am able to reproduce this issue with Asus Transformer Pad TF300T (Android 4.2.1) Regression window: Last good revision: 2014-06-25 First bad revision: 2014-06-26 Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a19e0434ea52&tochange=464bca437658
Keywords: regressionwindow-wanted
Comment 25•10 years ago
|
||
(In reply to Cristina Madaras, QA [:CristinaM] from comment #24) > Pushlog: > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=a19e0434ea52&tochange=464bca437658 Nothing obvious in that window that would cause this. snorp, care to do local build bisection? I'll look at the log too but considering there's almost zero gfx/ changes in that range I don't think the bug will turn up in the low-precision painting code.
Reporter | ||
Comment 26•10 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #25) > (In reply to Cristina Madaras, QA [:CristinaM] from comment #24) > > Pushlog: > > https://hg.mozilla.org/mozilla-central/ > > pushloghtml?fromchange=a19e0434ea52&tochange=464bca437658 > > Nothing obvious in that window that would cause this. snorp, care to do > local build bisection? I'll look at the log too but considering there's > almost zero gfx/ changes in that range I don't think the bug will turn up in > the low-precision painting code. I reproduced this bug in 33, so I don't see how this range could be valid unless it got fixed and rebroken at some point.
Reporter | ||
Comment 27•10 years ago
|
||
Nevermind, I guess that range is actually within 33.
Reporter | ||
Comment 28•10 years ago
|
||
I can reproduce it in Firefox 32, so that range is not valid.
Comment 29•10 years ago
|
||
So the log indicates that the critical displayport is 1176 CSS pixels tall and the low-res displayport is 1243.93 CSS pixels tall. So the bottom of the page is rendered in low-res (and that's what you're seeing). Also according to the metrics we're at the max scroll position (y=687.017, which approximately makes sense given the page height of 1243.93 and the comp bounds height of 556.41). So the question is why didn't the critical displayport move down further to encompass the bottom of the page. Instead it's just rendering the top of the page (which is out of view) in high-res.
Reporter | ||
Comment 30•10 years ago
|
||
Last good revision: 9d8d16695f6a (2014-05-21) First bad revision: b40296602083 (2014-05-22) Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d8d16695f6a&tochange=b40296602083
Reporter | ||
Comment 31•10 years ago
|
||
There is some displayport/margin stuff in that log, so it seems plausible. Trying to bisect inbound now. Kats looks like the winner, though :)
Comment 32•10 years ago
|
||
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #30) > Last good revision: 9d8d16695f6a (2014-05-21) > First bad revision: b40296602083 (2014-05-22) > Pushlog: > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=9d8d16695f6a&tochange=b40296602083 Bug 1001438?
Comment 33•10 years ago
|
||
Almost certainly, yes. snorp and I were discussing on IRC and I had him add some logging around the code that sets the displayport margins in browser.js. Pasting the relevant hits here so we don't lose it: ContainerLayerComposite (0x89e0ac00) [shadow-clip=(x=0, y=0, w=1920, h=1090)] [shadow-transform=[ 1.70596 0; 0 1.70596; 0 -110.877; ]] [shadow-visible=< (x=0, y=0, w=1920, h=1091); >] [clip=(x=0, y=0, w=1920, h=1090)] [postScale=0.765625, 0.765625] [transform=[ 1.30612 0; 0 1.30612; 0 0; ]] [visible=< (x=0, y=0, w=1920, h=1091); >] [metrics0={ cb=(x=0.000000, y=0.000000, w=1920.000000, h=1090.000000) sr=(x=0.000000, y=0.000000, w=980.000000, h=1243.933350) s=(0,687.017) dp=(x=0.000000, y=-687.016663, w=980.000000, h=1243.933350) cdp=(x=0.000000, y=-687.016663, w=980.000000, h=1176.000000) color=rgba(255, 255, 255, 1) scrollId=3 z=1.959 }] [preScale=0.765625, 0.765625] SNORP: display port data: {"scrollx":0,"scrolly":1345.9591836734694,"zoom":1.9591836734693877,"documentScrollY":687,"gScreenWidth":1920,"gScreenHeight":1090.5,"gViewportMargins":{"top":84,"right":0,"bottom":0,"left":0},"aDisplayPort":{"left":0,"top":256,"right":1920,"bottom":2437,"resolution":1.9591837}} The aDisplayPort value that java sends seems reasonable, so the problem is either with gScreenHeight and/or gViewportMargins being wrong or in GetDisplayPortFromMarginsData. Not subtracting the gViewportMargins didn't fix the problem either which was pretty surprising.
Blocks: 1001438
Comment 34•10 years ago
|
||
[Tracking Requested - why for this release]: noticeable regression, shipped in 32 but it is bad enough we should track
tracking-firefox34:
--- → ?
tracking-firefox35:
--- → ?
tracking-firefox36:
--- → ?
Keywords: regression
Reporter | ||
Comment 35•10 years ago
|
||
So I see the following layer tree: 10-24 15:20:23.220 I/Gecko (10901): LayerManager (0x8b41b320) 10-24 15:20:23.220 I/Gecko (10901): ContainerLayerComposite (0x8c594400) [shadow-visible=< (x=0, y=0, w=1470, h=771); >] [visible=< (x=0, y=0, w=1470, h=771); >] [metrics0={ cb=(x=0.000000, y=0.000000, w=1920.000000, h=1090.000000) sr=(x=0.000000, y=0.000000, w=1280.000000, h=726.666687) s=(0,0) dp=(x=0.000000, y=0.00000 0, w=0.000000, h=0.000000) cdp=(x=0.000000, y=0.000000, w=0.000000, h=0.000000) color=rgba(0, 0, 0, 0) scrollId=0 z=1.500 }] 10-24 15:20:23.220 I/Gecko (10901): ContainerLayerComposite (0x8c594c00) [shadow-clip=(x=0, y=0, w=1920, h=1090)] [shadow-transform=[ 1.70596 0; 0 1.70596; 0 0; ]] [shadow-visible=< (x=0, y=0, w=1920, h=1008); >] [clip=(x=0, y=0, w=1920, h=1090)] [postScale=0.765625, 0.765625] [transform=[ 1.30612 0; 0 1.30612; 0 0; ]] [visible=< (x=0, y=0, w=1920, h=1008); >] [metrics0={ cb=(x=0.000000, y=0.000000, w=1920.000000, h=1006.497925) sr=(x=0.000000, y=0.000000, w=980.000000, h=513.733337) s=(0,0) dp=(x=0.000000, y=0.000000, w=980.000000, h=513.733337) cdp=(x=0.000000, y=0.000000, w=980.000000, h=513.733337) color=rgba(255, 255, 255, 1) scrollI d=2 z=1.959 }] [preScale=0.765625, 0.765625] 10-24 15:20:23.220 I/Gecko (10901): PaintedLayerComposite (0x8c595000) [shadow-clip=(x=0, y=0, w=0, h=0)] [clip=(x=0, y=0, w=0, h=0)] [not visible] 10-24 15:20:23.220 I/Gecko (10901): ColorLayerComposite (0x8c594000) [shadow-visible=< (x=0, y=0, w=1920, h=1006); >] [bounds=(x=0, y=0, w=1920, h=1006)] [visible=< (x=0, y=0, w=1920, h=1006); >] [opaqueContent] [color=rgba(255, 255, 255, 1)] This has a root layer that is 1470x771. Where is that coming from? The child directly under it has a size that looks reasonable, 1920x1090. Is this expected?
Comment 36•10 years ago
|
||
The 1470 is 1920 * 0.765625. The 771 does seem a little shorter than I would expect. Based on the logging you showed me on IRC it's likely this is related to the base rect being too short which is what ultimately results in the critical displayport not extending all the way down.
Comment 37•10 years ago
|
||
Can track this, but it should get into the beta before end of next week - not urgent enough to crash land in the last 2 weeks of beta since we did ship this twice already.
Reporter | ||
Comment 38•10 years ago
|
||
Robin Andersen ran into a variant of this today too. First time I've seen it on a phone (Nexus 5). https://www.dropbox.com/s/8vghwqaq30m6ez8/Screenshot_2014-10-28-14-19-56.png?dl=0 This is with the Privacy Coach add-on. I couldn't reproduce that locally on my phone.
Reporter | ||
Comment 39•10 years ago
|
||
Timothy do you have any idea what could be going on here?
Flags: needinfo?(tnikkel)
Assignee | ||
Comment 40•10 years ago
|
||
I can't reproduce this myself, but comment 36 pointed me in this direction. This code seems wrong and would likely cause something exactly like this. snorp, would you mind testing this to see if it fixes the problem for you?
Flags: needinfo?(tnikkel)
Attachment #8513094 -
Flags: feedback?(snorp)
Reporter | ||
Comment 41•10 years ago
|
||
(In reply to Timothy Nikkel (:tn) from comment #40) > Created attachment 8513094 [details] [diff] [review] > a guess > > I can't reproduce this myself, but comment 36 pointed me in this direction. > This code seems wrong and would likely cause something exactly like this. > > snorp, would you mind testing this to see if it fixes the problem for you? It fixes it here, nice catch! Let's get this in and uplifted ASAP.
Reporter | ||
Updated•10 years ago
|
Attachment #8513094 -
Flags: feedback?(snorp) → feedback+
Assignee | ||
Comment 42•10 years ago
|
||
Botond, do you think you can review this?
Assignee: snorp → tnikkel
Attachment #8513094 -
Attachment is obsolete: true
Attachment #8513909 -
Flags: review?(botond)
Assignee | ||
Comment 43•10 years ago
|
||
Oops, accidentally removed the android ifdef that I did not intend to do.
Attachment #8513909 -
Attachment is obsolete: true
Attachment #8513909 -
Flags: review?(botond)
Attachment #8513913 -
Flags: review?(botond)
Comment 44•10 years ago
|
||
Comment on attachment 8513913 [details] [diff] [review] patch Review of attachment 8513913 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/base/nsLayoutUtils.cpp @@ +6796,5 @@ > + ParentLayerRect frameRectPixels = > + LayoutDeviceRect::FromAppUnits(frameRect, auPerDevPixel) > + * layoutToParentLayerScale; > + if (frameRectPixels.height < ParentLayerRect(ViewAs<ParentLayerPixel>(widgetBounds)).height) { > + size.height = frameRect.height; This assignment doesn't seem correct. If the frame size in pixels needs to be multiplied by a scale before it can be compared to the widget bounds in pixels, then I would think the frame size in app units needs to be multiplied by that same scale before being assigned to 'size' (which was initialized with the widget bounds in app units). For example, suppose auPerDevPixel = 60 cumulativeResolution = 3 frameRect.height = 6000 app units = 100 LD pixels = 300 PL pixels widgetBounds.height = 400 LD/PL pixels = 24000 app units Then the code will do: if (300 < 400) { // size.height used to be 24000 size.height = 6000; } whereas I think we want it to do: if (300 < 400) { // size.height used to be 24000 size.height = 18000; }
Comment 45•10 years ago
|
||
Comment on attachment 8513913 [details] [diff] [review] patch Review of attachment 8513913 [details] [diff] [review]: ----------------------------------------------------------------- Dropping review flag until comment 44 is addressed.
Attachment #8513913 -
Flags: review?(botond)
Assignee | ||
Comment 46•10 years ago
|
||
After much thought I think you are right. It's just very rare that we need to convert from app units to appunits and scale by the resolution.
Attachment #8513913 -
Attachment is obsolete: true
Attachment #8517906 -
Flags: review?(botond)
Updated•10 years ago
|
Attachment #8517906 -
Flags: review?(botond) → review+
Assignee | ||
Comment 47•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/9ee314a76de3
Comment 48•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/9ee314a76de3
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Comment 49•10 years ago
|
||
We're about to ship 34 beta8. I don't want to take this fix in the last beta. As such, marking as won't fix in 34. I would like to see this fixed in 35. Can you please nom if you're ok with the uplift?
Flags: needinfo?(tnikkel)
Assignee | ||
Comment 50•10 years ago
|
||
Comment on attachment 8517906 [details] [diff] [review] patch v2 Approval Request Comment [Feature/regressing bug #]: bug 1001438 [User impact if declined]: low res used to draw parts of page that are visible [Describe test coverage new/current, TBPL]: not much sadly [Risks and why]: this should be pretty safe, we compute the composition bounds like this everywhere else, just this one place was wrong [String/UUID change made/needed]: none
Flags: needinfo?(tnikkel)
Attachment #8517906 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
Attachment #8517906 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 54•10 years ago
|
||
The blurry section doesn't appear anymore, so I will mark this as verified. Builds: Firefox for Android 35.0a2 (2014-11-13) Firefox for Android 36.a01 (2014-11-13) Device: Asus Transformer TF101 (Android 4.0.3) Acer Iconia Tab (Android 3.0)
Comment 55•9 years ago
|
||
I still experience blurry bottom of some pages when I have "Full-screen browsing" disabled to always see address bar. - Zoom out to full page width (or double tap to zoom) doesn't work (unless overridden in settings or before rotating from landscape) or causes blurry or missing parts of page I can replicate this issue with both latest stable 37.0.2 and nightly 40.0a1when visiting and zooming page https://www.ceskaposta.cz/sluzby/psani (or other pages on this domain of Czech post). I teated it on Samsung Galaxy S5 (stock 4.4.2), Samsung Galaxy Tab S 8.4 (stock 4.4.2), and LG G Pad 8.3 (CM11 - Android 4.4.4).
Comment 56•9 years ago
|
||
This bug was resolved. Please file a new bug as in all likelihood you're seeing a new or different problem.
Updated•3 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
•