Closed Bug 1072789 Opened 5 years ago Closed 5 years ago
[Email] Message list scrolling area/layer fails to paint / paints all black (widgets on top may still paint)
[Blocking Requested - why for this release]: [Device] Flame [Environment] Gaia-Rev a7e53d661a1329d6813bc6104555b57dbb5e4d85 Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/84d2b47c102d Build-ID 20140924160202 Version 34.0a2 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20140922.221301 FW-Date Mon Sep 22 22:13:10 EDT 2014 Bootloader L1TC10011800 [STR] 1. Launch email app 2. Set up email account/ pwd 3. After set up account complete, it will go into the mail list page. 4. Drop down / or drop up mail list [Actually result] 1. Mail list page will be displayed to black page [Expected result] 1. Mail list page must display normally. [Attachment] 1. email_logcat.txt 2. http://youtu.be/RuRn6wyya-E
Moving to graphics for duping; graphics people note that there's a video. We can probably provide a layer dump if this is somehow not a dupe.
Component: Gaia::E-Mail → Graphics
Product: Firefox OS → Core
Summary: [Email] Mail list page will be displayed to black page → [Email] Message list scrolling area/layer fails to paint / paints all black (widgets on top may still paint)
[update] Moving to graphics QA handle it.
blocking-b2g: 2.1? → ---
QA Whiteboard: [COM=Gaia::E-Mail]
QA Contact: edchen
Uh, but using the right flag. [Blocking Requested - why for this release]: It is hard to read emails if you can't see them ;)
Adding qawanted for branch checks.
This issue is occurring in 2.1 Flame. Environmental Variables: Device: Flame 2.1 (Shallow Flash) BuildID: 20141001105624 Gaia: c1cc61e30f5cb3446f1692ff9fd1e32232f6a231 Gecko: 3b859b93de23 Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Result: Mail list would turn black while scrolling ----------------------------------------------------------- This issue is not occurring in 2.2 Flame and 2.0 Flame. Environmental Variables: Device: Flame 2.2 Master (Shallow Flash) BuildID: 20141001060621 Gaia: a23d2c490b39c4699c9375e25c4acdf396a2fa85 Gecko: 835ef55e175e Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Device: Flame 2.0 (Shallow Flash) BuildID: 20141001060124 Gaia: 8079cba2133e6f5443dba24dad077f7f91e6c978 Gecko: 66c1ea78b6c1 Version: 32.0 (2.0) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Result: The screen remained normal while scrolling through emails
QA-Wanted - please do a quick dupe check before starting on the window based on it being unaffected in Master - I've seen several 2.1-only as affected due to being dupe or similar of bugs already fixed in master but not yet uplifted to 2.1
QA Whiteboard: [QAnalyst-Triage?]
QA Contact: aalldredge
(In reply to Joshua Mitchell [:Joshua_M] from comment #8) > QA-Wanted - please do a quick dupe check before starting on the window based > on it being unaffected in Master - I've seen several 2.1-only as affected > due to being dupe or similar of bugs already fixed in master but not yet > uplifted to 2.1 The best candidate for duplicate would be bug 1063046, but that was uplifted to Aurora/2.1 on 9/26, so should have been in the nightly since 9/27 at the latest; comment 7 suggests we're beyond that.
Assignee: nobody → bgirard
Kats, related to anything we're looking at in APZ right now? QA - can this be reproduced with low res tiling disabled?
Probably unrelated, but this was an interesting bug with similar symptoms - bug 1052256.
This looks very much like a dupe of bug 1070993. The ranges seem to agree with that I think.
That should be easy enough to check - bug 1070993 landed on Aurora/2.1 10/1, so should be in the latest nightly
This issue is not reproducing the same way in the latest Aurora build. It is only reproducing when the list is scrolled very quickly. Video uploaded at http://youtu.be/snsHagZVy6k. Environmental Variables: Device: Flame 2.1 BuildID: 20141003063135 Gaia: 88f431fcf75f274d9db66b9d3c8af7b6dc29edb1 Gecko: 4bdbaa7fefcb Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
This is expected behaviour. The background color closest to the scrollable area is black, so when you scroll super-fast and get checkerboarding, we will just paint black. If you want to change the black to white so that it's less noticeable that would require a change in the email app's CSS somewhere.
It's probably better to file a new bug against the email app if you want that change; closing this as a dupe of 1070993.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1070993
Note that the post-fix behaviour is a little weirder than comment 14 when I reproduce it. Specifically, if I scroll super fast, I see us go through the following states: 1) High res-tiled 2) Low res-tiled 3) White checkerboarding (very short-lived) 4) Black checkerboarding Our DOM hierarchy and background colors to the scrollable part are nested like so: - html: overflow-hidden - body: background-color: black; - div.cardContainer - div.cards - div.card-message-list: background-color: #fff - div.msg-list-scrollouter: overflow-y: auto, overflow-x: hidden (the scrolly bit) - div.msg-list-scrollinner (the thing that gets scrolled) - div.msg-messages-container: background-color: #fff (this is most of the thing that gets scrolled, but there is also the search bar header and some other stuff. It seems like we are "tearing through" our white checkerboarding color because it requires some thought to figure out the checkboarding color? If I add "background-color: white" to .msg-list-scrollouter via the devtools, then we checkerboard tear to be white *except* when we hit the top/bottom and encounter the search <form> and the div.msg-messages-sync-container; those are initially black, which is weird to me. But maybe the dynamic devtools update was insufficient? Either way, we should probably spin-off setting the background-color: white; thing at least on .msg-list-scrollouter. Except I'm also scared about affecting our paint performance... so, ni'ing :jrburke as the authoritative keeper on how we avoid regressing that too, although I do agree we should spin off a separate email-bug.
[Environment] Gaia-Rev 778ebac47554e1c4b7e9a952d73e850f58123914 Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/aa98eb8873a2 Build-ID 20141005160206 Version 34.0a2 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20140925.192608 FW-Date Thu Sep 25 19:26:18 EDT 2014 Bootloader L1TC10011800 [Result] PASS
Status: RESOLVED → VERIFIED
I posted my investigation in bug 1077605 comment 4, clearing the needinfo here.
You need to log in before you can comment on or make changes to this bug.