Closed Bug 1031494 Opened 6 years ago Closed 5 years ago

Scrolling in the Persona window will cause text elongation/ white out

Categories

(Core :: Panning and Zooming, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla33
blocking-b2g 2.0+
Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
b2g-v1.4 --- unaffected
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: nhirata, Assigned: kats)

References

Details

(Keywords: regression)

Attachments

(3 files)

1. launch marketplace
2. select settings
3. select My Apps
4. select Sign in
5. select link Privacy Policy 
6. scroll down

Expected: text does not elongate
Actual: text elongates displayed text blurs, whites out for 3 to 4 seconds

Gaia      8df02268fcd7e80c5fab8c1ec099772e37f8659d
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/731a5e8831e6
BuildID   20140627000201
Version   32.0a2
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
Flame

Vid : http://www.youtube.com/watch?v=kqVLR03_Io8&feature=youtube_gdata_player
The text doesn't elongate on 1.4 buri it does white out; the white out only occurs for a split second.

Gaia      a054aa221df20ca550e6c67f3fbb20d0ad086598
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/e054ac1b5408
BuildID   20140626000203
Version   30.0
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013
Buri.
Looks like a possible gonk issue.  The text blurrs instead of whites with Buri running 2.0 and comes back to within a split second.
Component: Gaia::System → GonkIntegration
Turns out this OOM'ed the graphics on the buri when the buri went to sleep.

FYI, Sotaro.
Flags: needinfo?(sotaro.ikeda.g)
Need a video.
Keywords: qawanted
Keywords: regression
Link from Naoki
Vid : http://www.youtube.com/watch?v=kqVLR03_Io8&feature=youtube_gdata_player

If there is a different video you need let me know.
QA Whiteboard: [QAnalyst-Triage?]
Keywords: qawanted
QA Contact: croesch
Don't forget that you need to ask Josh to review.
Flags: needinfo?(croesch)
Flags: needinfo?(croesch) → needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
I don't think the flag should be cleared here - the triage work isn't finished here & there's no QA Wanted tag included here.
Flags: needinfo?(jmitchell)
You are too fast for me Jason! 

Qa-wanted for Branch check
Flags: needinfo?(jmitchell)
Keywords: qawanted
This bug repro's on: Flame 2.1 Master, Flame 2.0, Flame 1.4, Buri 2.1

Actual Results: Scrolling through the Privacy Policy in the Marketplace results in text disappearing temporarily, blurry text and elongated text.

Flame 1.4: Scrolling to go back to the top of the Privacy Policy displays white parts for a split second only before text repopulates. No other symptoms seen.

Environmental Variables:
Device: Flame Master
Build ID: 20140630063630
Gaia: bc3bbf42d2a606f6b7038881cff5ec3795fdf953
Gecko: 3b46de297f3f
Version: 33.0a1 (Master)
Firmware Version: v122
---------------------------------------------
Environmental Variables:
Device: Flame 2.0
Build ID: 20140630085228
Gaia: 564ab3935206a6979b317597020f47aebe8c80fe
Gecko: 7974d58adda4
Version: 32.0a2 (2.0)
Firmware Version: v122
---------------------------------------------
Environmental Variables:
Device: Flame 1.4
Build ID: 20140629211929
Gaia: aa896d5db1b4929f3bf31a0f4bb7de50530222a8
Gecko: 8cba60bc12ef
Version: 30.0 (1.4)
Firmware Version: v122
---------------------------------------------
Environmental Variables:
Device: Buri Master
Build ID: 20140630063630
Gaia: bc3bbf42d2a606f6b7038881cff5ec3795fdf953
Gecko: 3b46de297f3f
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
I wanted to flip the 1.4 flag to affected because there is the white screen for a split second when scrolling, but I did not flip it because it was already set as unaffected previously.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Josh - This is missing a blocking triage assessment.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review-]
Flags: needinfo?(jmitchell)
Nomming as a 2.0 blocker - issue looks very bad and is easily encountered by anyone clicking the link mentioned.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage+][lead-review-] → [lead-review-]
Flags: needinfo?(jmitchell)
QA Contact: croesch → pcheng
There are 3 separate issues in this bug.

When excessively scrolling the following can happen:

1) White screen appears until scrolling slows down. This bug has always been there since APZ was enabled by default sometime this January or end of last year. With the exception of Buri 2.1, see 3)

2) Text elongation + prolonged white screen - only observed on Flame, also the reason why I used
Flame to find the window.

3) Blurry text - Observed on latest Buri 2.1 in place of 1). Also observed on latest Flame 2.1 but not in my first broken & last working builds.

Mozilla inbound regression window:

Last Working (the above-mentioned 1 occurs)
Device: Flame
Build ID: 20140529073016
Gaia: 4142df90c71abdc1e3a87cd37dff1a22d5e38b34
Gecko: 1c823c4af278
Version: 32.0a1 (Master)
Firmware Version: v122

First broken (the above-mentioned 1+2 occurs)
Device: Flame
BuildID: 20140529103002
Gaia: b669dd2cc321f37cebc7081a79b968cac36b4200
Gecko: 29ca8bc78484
Version: 32.0a1 (Master)
Firmware Version: v122

First broken gecko & last working gaia- (2) occurs
Gaia: 4142df90c71abdc1e3a87cd37dff1a22d5e38b34
Gecko: 29ca8bc78484

First broken gaia & last working gecko - (2) does NOT occur
Gaia: b669dd2cc321f37cebc7081a79b968cac36b4200
Gecko: 1c823c4af278

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1c823c4af278&tochange=29ca8bc78484

Josh and I couldn't determine which bug(s) might have caused this. Leaving this to the devs.
QA Whiteboard: [lead-review-] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
comment 13 is incredibly confusing. Can we have a window written here for the bug as filed here & have separate bugs filed for the other bugs seen?
QA Whiteboard: [QAnalyst-Triage+] → [lead-review-]
Flags: needinfo?(pcheng)
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #14)
> comment 13 is incredibly confusing. Can we have a window written here for
> the bug as filed here & have separate bugs filed for the other bugs seen?

The window covers this bug (effects 1 and 2 - as per the bug subject) -  I will have someone file a separate bug for the other.
Flags: needinfo?(pcheng)
(In reply to Joshua Mitchell (Joshua_M) from comment #15)
> (In reply to Jason Smith [:jsmith] from comment #14)
> > comment 13 is incredibly confusing. Can we have a window written here for
> > the bug as filed here & have separate bugs filed for the other bugs seen?
> 
> The window covers this bug (effects 1 and 2 - as per the bug subject) -  I
> will have someone file a separate bug for the other.

[1] technically is checkerboarding, which I don't think is the focus of this bug. This bug is talking about a permanent whiteout, which is [2].
kats - The range above shows that bug 897996 is included in the list. Do you think this is a regression from that bug?
Flags: needinfo?(bugmail.mozilla)
Keywords: qawanted
From comment 13, item (1) is just checkerboarding. item (2) is a bug. IIRC Alex Lissy ran into this bug before but only on specific devices and I was never able to reproduce it. item (3) is expected behaviour; that's the low-precision rendering fallback for checkerboarding.

Assuming the range given in comment 13 is for item (2) then I guess my changes are the most likely. It should be easy enough to disable low-precision rendering and progressive painting to verify this. I'll see if I can reproduce and confirm if this was caused by my changes or not. Leaving ni for the moment.
I can reproduce this and disabling both progressive-paint and low-precision-buffer does appear to fix it.
Blocks: 993473
Component: GonkIntegration → Panning and Zooming
Flags: needinfo?(bugmail.mozilla)
Product: Firefox OS → Core
Version: unspecified → Trunk
blocking-b2g: 2.0? → 2.0+
Assignee: nobody → bugmail.mozilla
There's definitely something fishy with that pop-up persona window. I added a call to Dump() in ClientLayerManager::EndTransactionInternal which gets hit continuously even when I'm idling on that window. For some reason layout is continuously painting that window. This happens even if I disable progressive-paint and low-precision-buffer. It happens on both the screen with the persona input box and the privacy policy page (and probably anything in that popup window)

What's even weirder is that there is a layer in the layer dump whose transform is also continuously changing. Attached is the output of "adb logcat | grep 0xb15f0000" which is the layer in question. I don't understand why the transform would change like that per paint while nothing is visibly changing on the screen.
It's probably some sort of CSS animation actually, and unrelated to the main problem here. I'll file a separate bug for that eventually.
It seems that this stretching business happens when the size the of the low-res displayport exceeds 4096 layoutdevice pixels. I'm not entirely sure why this should matter because the size in layer pixels will still be a quarter of that (because of the low-precision-resolution) but for some reason it does. If I clamp the result of GetDisplayPortFromMarginsData to 4096x4096 this doesn't happen.
So the displayport controls the size of the visible region set on the layer in RecordFrameMetrics, which is the thing that actually matters here. When that visible region exceeds 4096 pixels tall the layer gets stretched.
Digging deeper, it seems like the code at [1] clamps the surface dimensions to the max texture size, but does so without maintaining the aspect ratio. This results in the stretching effect seen.

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/ContainerLayerComposite.cpp?rev=2186f79e926c#312
Attached patch PatchSplinter Review
This fixes it. If I *do* change the code so that the clamped rect maintains the aspect ratio of the unclamped rect, then stuff breaks (that is, the content gets stretched horizontally rather than vertically). I don't really understand why, but if I leave otu the aspect ratio stuff then it works just fine.
Attachment #8451176 - Flags: review?(bgirard)
Comment on attachment 8451176 [details] [diff] [review]
Patch

Review of attachment 8451176 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM
Attachment #8451176 - Flags: review?(bgirard) → review+
https://hg.mozilla.org/mozilla-central/rev/da3f630c0676
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Flags: needinfo?(sotaro.ikeda.g)
This issue has been successfully verified on Flame v2.1&2.0.
See attachment: verified_v2.1.mp4
Reproducing rate: 0/5

Flame 2.1 build:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141202001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141202.034824
FW-Date         Tue Dec  2 03:48:34 EST 2014
Bootloader      L1TC00011880

Flame 2.0 build:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141202000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141202.034707
FW-Date         Tue Dec  2 03:47:18 EST 2014
Bootloader      L1TC00011880
You need to log in before you can comment on or make changes to this bug.