52.76 KB, image/png
282.99 KB, text/plain
248.81 KB, image/png
46 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
2.12 MB, video/mp4
Created attachment 8434393 [details] Slider.png Description: The scrollbar is sliding extremely fast when scrolling through contacts Repro Steps: 1) Update a Flame to 20140604040204 2) Open Contacts app 3) Import or manually add 100 contacts 4) On the contacts page quickly scroll through the contacts Actual: The scrollbar is being improperly displayed. Expected: The scrollbar is always visible and scrolls correctly. Environmental Variables: Device: Flame Build ID: 20140604040204 Gaia: 1d4f6f7312882e78b57971152de75d1281a26187 Gecko: 668f29cd71b3 Version: 32.0a1 (2.0) Firmware Version: v10G-2 User Agent: Mozilla/5.0 (Mobile;rv:32.0) Gecko/32.0 Firefox/32.0 Notes: Repro frequency: 100% See attached: https://www.youtube.com/watch?v=6gDHzTNjbSs Screenshot, and logcat
Created attachment 8434394 [details] log.txt Issue DOES repro on 2.0 Buri. Issue does NOT repro on 1.4 Flame Environmental Variables: Device: Flame Build ID: 20140604000202 Gaia: 0c16adced7c51f795ef250aebe184f60b6a9b987 Gecko: 04216748e6c1 Version: 30.0 (1.4) Firmware Version: v10G-2
status-b2g-v1.4: --- → unaffected
Keywords: regression, regressionwindow-wanted
Summary: [B2G][Contacts]The scrollbar intemittently appears when scrolling fast through contacts → [B2G][Contacts]The scrollbar intermittently appears when scrolling fast through contacts
Part of the phone isn't showing in the video, so I'm having trouble understanding how fast you are scrolling here to cause the scrollbar to not to appear. I also need to understand what's seen on 1.4 here as well. Can we get a clearer video here on 2.0 & 1.4?
Keywords: regressionwindow-wanted → qawanted
It was my impression the visual design of the contacts app did not show the scrollbar at all. I thought we just showed the alpha jump bar instead. It looks like we're still trying to hide it: https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/style/app.css#L317 https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/index.html#L114
(In reply to Jason Smith [:jsmith] from comment #2) > Part of the phone isn't showing in the video, so I'm having trouble > understanding how fast you are scrolling here to cause the scrollbar to not > to appear. I also need to understand what's seen on 1.4 here as well. > > Can we get a clearer video here on 2.0 & 1.4? Flame 2.0 video = https://www.youtube.com/watch?v=ISM0Mjxuy0U Flame 1.4 video = https://www.youtube.com/watch?v=VjtrNkRdXx0
QA Contact: mclemmons
Minor regression overall.
Component: Gaia::Contacts → Panning and Zooming
Product: Firefox OS → Core
Version: unspecified → 32 Branch
From the 2.0 video in comment 4 it looks to me like this isn't the scrollbar at all but an artifact of low-res drawing. It's hard to tell for sure though because the video isn't that clear. If you can disable low-res drawing (set the "layers.low-precision-buffer" pref to false) or go back to a version before bug 897996 landed and see if it goes away that would confirm my theory. (Note that bug 897996 was backed out the first time it landed so make sure you pick a build where it was not in the tree).
QA-Wanted to address comment 6
(In reply to Kartikaya Gupta (email:email@example.com) from comment #6) > From the 2.0 video in comment 4 it looks to me like this isn't the scrollbar > at all but an artifact of low-res drawing. It's hard to tell for sure though > because the video isn't that clear. If you can disable low-res drawing (set > the "layers.low-precision-buffer" pref to false) or go back to a version > before bug 897996 landed and see if it goes away that would confirm my > theory. (Note that bug 897996 was backed out the first time it landed so > make sure you pick a build where it was not in the tree). \\ I tested on 4/27 build before the patch landed 4/28 on comment https://bugzilla.mozilla.org/show_bug.cgi?id=897996#c6 The issue does NOT reproduce. Environmental Variables: Device: Flame Build ID: 20140527040202 Gaia: 6a391274cd436f8f0d1fad2db8c6b4805703259c Gecko: cbe4f69c2e9c Version: 32.0a1 (2.0) Firmware Version: v121-2
QA Whiteboard: [QAnalyst-Triage?]
Summary: [B2G][Contacts]The scrollbar intermittently appears when scrolling fast through contacts → [B2G][Contacts]Low-precision drawing results in unsightly artifacts when scrolling fast
Created attachment 8442242 [details] Screenshot with layer borders enabled I'm not entirely sure why this is happening. I forced low-precision drawing always, to be able to see it up close. You can see in the screenshot how on one tile (that ends halfway through Charles Long) there is a black line down the right side. That isn't present on the next tile, although there are a few pixels of black between the Q and the R in the jumpbar. As I scroll around I see similar things all over the place that seem to be inconsistent (and change on redraws). My guess right now is that the low-res tile is one pixel too narrow, possibly due to rounding, and so a one-pixel stripe of random garbage underneath is visible.
Somehow this seems very specific to the layout of the app. The groups-container element in the contacts app has a right padding of 15px (1.5rem technically) and if I change it to 14px or 16px then the fat black line is replaced by a barely-noticeable 1px black line. I think the line (not sure where it's coming from yet) just happens to land in a place where the low-res scaling makes it look really ugly.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Assignee: nobody → bugmail.mozilla
Not actively looking at this right now because I have other things at the moment that are more important. Also I suspect there's won't be a lot we can do about this on the platform side.
Assignee: bugmail.mozilla → nobody
I investigated this a bit more and tracked down the root cause. It looks like in the contacts app, the div id="groups-container" has a width of 100% + 1rem so that it's wide enough to put the scrollbar offscreen. However, of that width, 1.5rem is taken up by padding-right, so the groups-container content width is actually less than the screen width. This ends up causing a 5-pixel gap on the right side which is what causes the ugly black line to show up in low-precision drawing mode. Changing the groups-container width to 100% + 1.5rem fixes the problem.
Assignee: nobody → bugmail.mozilla
Created attachment 8463441 [details] [review] Gaia PR
Attachment #8463441 - Flags: review?(francisco)
Component: Panning and Zooming → Gaia::Contacts
Product: Core → Firefox OS
Version: 32 Branch → unspecified
Comment on attachment 8463441 [details] [review] Gaia PR Hi Michal, would you mind to take the review here?
Attachment #8463441 - Flags: review?(francisco) → review?(mbudzynski)
I cannot see any scrollbar on fresh Flame build, with or without this patch. As far as I understand, it should be visible all the time when scrolling, right?
No, the scrollbar should be hidden all the time; the contacts app CSS does that explicitly. This bug is about a blurred black bar that appears on the right side of the screen when scrolling fast.
Comment on attachment 8463441 [details] [review] Gaia PR I couldn't reproduce this bug with this patch applied. Thanks Kartikaya!
Attachment #8463441 - Flags: review?(mbudzynski) → review+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-b2g-v2.1: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S1 (1aug)
Created attachment 8533033 [details] Verify_Video_Flame.MP4 According to comment 16, This issue has been verified successfully on Flame 2.1. See attachment: Verify_Video_Flame.MP4 Reproducing rate: 0/10 Flame v2.1 version: Gaia-Rev 38e17b0219cbc50a4ad6f51101898f89e513a552 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a Build-ID 20141205001201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141205.035305 FW-Date Fri Dec 5 03:53:16 EST 2014 Bootloader L1TC00011880
You need to log in before you can comment on or make changes to this bug.