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)

ARM
Android
defect
Not set
normal

Tracking

(firefox33 wontfix, firefox34+ wontfix, firefox35+ verified, firefox36+ verified, fennec34+)

VERIFIED FIXED
Firefox 36
Tracking Status
firefox33 --- wontfix
firefox34 + wontfix
firefox35 + verified
firefox36 + verified
fennec 34+ ---

People

(Reporter: snorp, Assigned: tnikkel)

References

()

Details

(Keywords: regression)

Attachments

(5 files, 4 obsolete files)

Attached image blurry-bottom.png
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.
Kats: any ideas?
tracking-fennec: --- → ?
Flags: needinfo?(bugmail.mozilla)
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)
You are thinking of bug 1058272.
Yeah, this blurriness never goes away, so it's a little different.
This is busted on 32 too, so if it's a regression then it's pretty old.
Err, I mean 33.
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.
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
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.
Milan, can we get an assignee?
Assignee: nobody → milan
Kats, maybe you can take a quick look at this since it seems vaguely viewport related?
Flags: needinfo?(bugmail.mozilla)
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)
It reproduced just on devices with full HD resolution(1920×1080). I checked on two different devices Nexus 10 and dragonboard.
For those that can reproduce, any chance of getting a regression range?
Assignee: milan → nobody
(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)
(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)
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.
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)
Assignee: nobody → snorp
tracking-fennec: ? → 34+
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)
Attachment #8510490 - Attachment is obsolete: true
Flags: needinfo?(snorp)
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
(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.
(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.
Nevermind, I guess that range is actually within 33.
I can reproduce it in Firefox 32, so that range is not valid.
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.
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
There is some displayport/margin stuff in that log, so it seems plausible. Trying to bisect inbound now. Kats looks like the winner, though :)
(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?
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
[Tracking Requested - why for this release]: noticeable regression, shipped in 32 but it is bad enough we should track
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?
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.
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.
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.
Timothy do you have any idea what could be going on here?
Flags: needinfo?(tnikkel)
Attached patch a guess (obsolete) — Splinter Review
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)
(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.
Attachment #8513094 - Flags: feedback?(snorp) → feedback+
Attached patch patch (obsolete) — Splinter Review
Botond, do you think you can review this?
Assignee: snorp → tnikkel
Attachment #8513094 - Attachment is obsolete: true
Attachment #8513909 - Flags: review?(botond)
Attached patch patch (obsolete) — Splinter Review
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 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 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)
Attached patch patch v2Splinter Review
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)
Attachment #8517906 - Flags: review?(botond) → review+
https://hg.mozilla.org/mozilla-central/rev/9ee314a76de3
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
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)
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?
Attachment #8517906 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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)
Status: RESOLVED → VERIFIED
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).
This bug was resolved. Please file a new bug as in all likelihood you're seeing a new or different problem.
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

Created:
Updated:
Size: