Closed
Bug 1077605
Opened 10 years ago
Closed 10 years ago
[Email] Screen becomes black when scrolling through list fast
Categories
(Firefox OS Graveyard :: Gaia::E-Mail, defect)
Tracking
(b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 fixed)
VERIFIED
FIXED
2.1 S6 (10oct)
Tracking | Status | |
---|---|---|
b2g-v2.0 | --- | unaffected |
b2g-v2.1 | --- | verified |
b2g-v2.2 | --- | fixed |
People
(Reporter: AdamA, Assigned: jrburke)
References
()
Details
(Keywords: regression)
Attachments
(3 files)
Description:
When a user scrolls through a large list of emails quickly the screen will become black.
Repro Steps:
1) Update a Flame device to BuildID: 20141003063135
2) Open Email app
3) Log into an email account
4) Load more emails at least twice
5) Scroll through list quickly
Actual:
The screen becomes black while scrolling
Expected:
It is expected that the screen does not turn black when scrolling through emails quickly
Environmental Variables:
Device: Flame 2.1 (Shallow Flash)
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
Notes:
Repro frequency: 100%
See attached: video clip(http://youtu.be/snsHagZVy6k), logcat
Reporter | ||
Comment 1•10 years ago
|
||
This issue does not occur on 2.2 Flame or 2.0 Flame
Environmental Variables:
Device: Flame 2.2 Master (Shallow Flash)
BuildID: 20141003070740
Gaia: a8a6eed2ba9d66239aac789b9ee4900f911c73cb
Gecko: 388e101e75c8
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: 20141003065235
Gaia: 092d2b7678774c8b0b06dca0e0a8119e9eafdec3
Gecko: 43e53f774179
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Result:
Screen remains white when scrolling quickly.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0:
--- → unaffected
status-b2g-v2.1:
--- → affected
status-b2g-v2.2:
--- → unaffected
Flags: needinfo?(jmitchell)
Keywords: regression
Comment 2•10 years ago
|
||
It's interesting that this doesn't happen on 2.2. As far as I know the gecko side stuff should be the same between 2.1 and 2.2. Were there email app changes in 2.2?
Comment 3•10 years ago
|
||
Not Nomming, issue is graphic/polish only
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Assignee | ||
Comment 4•10 years ago
|
||
Bug 1072789 comment 17 has a good rundown of the DOM structure. I tried the suggestion of setting a background color of white on the message list's .msg-list-scrollouter, but that did not solve the issue that I was able to reproduce: intermittent drawing of black while actually scrolling.
I then changed the background color for the whole body to white (instead of black), and that fixed the issue for me.
It is a bit non-intuitive that setting the body to white makes a difference when a containing div for the card (div.card-message-list as mentioned in bug 1072789 comment 17) has white already set on it.
As to what is different in the email app between v2.1 and master, here is the diff (I removed the apps/email/test diffs since they just add noise):
https://gist.github.com/jrburke/ebac1994ef71a12b9d1e
It is hard to see how any of that affects this issue. No HTML structure changes, besides l10n stuff, and the CSS changes do not apply to the message list scroll area.
I observed frame rate and overpaint numbers before and after this body background change, nothing stuck out as noticeably, or even marginally different.
I observed startup perception too, what it looks like to the user as the email app is launched.
While ideally I would prefer to use a background: transparent on the body to get the first paint to be card UI, but that was changed in bug 948208 to black, for a broader cross-app paint flashing issue.
Moving to white for email seems to work out, since white is our background normally. Some notes for each case:
No account configured: a bit of white for a moment on very first launch, but then shows UI. Second load without an account is faster due to cookie cache, the white is almost imperceptible.
With account configured: cookie cache is active. The white paint fits in since it is the background color, and cookie cache snaps it in fast enough to not be an issue.
For activity triggers/notifications, we do not use the cookie cache. The white is shown longer, but I think it works out, as it is the background color. When no account is configured, it is maybe not as nice, but that should be a rarer case, and is really on screen so briefly that it is probably OK.
Using black as the background color can have the tendency to make the phone look dead for a moment, so there is probably some advantage to white in that case, as long as the white goes away fast enough. If it goes away fast enough though, then black is likely better.
-- summary --
It is notable that many gaia apps have the background set to black on the body. If they also have long lists of items on a white background, so a large div that can be scrolled like email's div, it would be interesting to know if QA can reproduce a similar failure there. It could be the root issue for some of the "I see black boxes painted" for some of the other apps.
It would be great to get to the root of the issue, as I expect it would affect other non-gaia apps also in some way, but in interests of improving the experience for email at this later date for 2.1, this patch does the trick for me.
Attachment #8500721 -
Flags: review?(bugmail)
Comment 5•10 years ago
|
||
Comment on attachment 8500721 [details] [review]
GitHub pull request
Thanks for the investigation and detailed description thereof and adding a comment so when we next play background-color whack-a-mole we'll have a quick reference to here to know why things are the way they are! :)
Attachment #8500721 -
Flags: review?(bugmail) → review+
Assignee | ||
Comment 6•10 years ago
|
||
Merged to master:
https://github.com/mozilla-b2g/gaia/commit/b62710782952ad84e72b08f903c7624e61e98f09
from pull request:
https://github.com/mozilla-b2g/gaia/pull/24853
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•10 years ago
|
||
Comment on attachment 8500721 [details] [review]
GitHub pull request
[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Not sure, likely platform changes. Discussion that triggered this spin off bug started in bug 1072789.
[User impact] if declined:
Fast scrolling in longer email lists looks glitchy.
[Testing completed]:
Tested on flame device, on master and on 2.1. Confirmed on 2.1 the black box artifacts while scrolling disappeared, now see white instead, which blends in more with the background of the scroll area.
[Risk to taking this patch] (and alternatives if risky):
No technical risk. The user visible change of using white as a starting color is described more in comment 4.
[String changes made]:
none
Attachment #8500721 -
Flags: approval-gaia-v2.1?
Updated•10 years ago
|
Attachment #8500721 -
Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Comment 8•10 years ago
|
||
Assignee: nobody → jrburke
Target Milestone: --- → 2.1 S6 (10oct)
Comment 10•10 years ago
|
||
This issue has been verified successfully on Flame 2.1
See attachment: Verify_video.3gp
Reproducing rate: 0/5
Flame2.1 build:
Gaia-Rev 1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID 20141125001201
Version 34.0
You need to log in
before you can comment on or make changes to this bug.
Description
•