Closed Bug 970422 Opened 6 years ago Closed 6 years ago
[B2G][Messages] Scroll bar is displayed behind messages that have been sent
Description: When scrolling through a message conversation with several messages or images, the scroll bar with be displayed under messages. Repro Steps: 1) Updated Buri to BuildID: 20140210004002 2) Navigate to Messages App 3) Send multiple MMS and SMS to another device 4) Scroll down the thread Actual Result: Scroll bar is displayed behind messages Expected Result: Scroll bar is not displayed behind messages Environmental Variables: Device: Buri v1.3 mozRIL BuildID: 20140210004002 Gaia: 5c8416fb1ea4a27f172ee6386ab3c19135448506 Gecko: 9c9382f433c0 Version: 28.0 v1.2-device.cfg Attached: screenshot
Kats, can you look at the attachment and tell us if this could be an effect of APZC ? Not that it's an important bug...
If it still happens with APZC disabled then it's unrelated to APZC. That being said, if this changed recently, then it might be the result of bug 965593 and is intentional (see comment 33 on that bug).
Does this reproduce with APZC disabled? Does this reproduce on 1.1?
The issue does not reproduce with the latest Buri v1.1 build. I disabled APZC then restarted the device and was still able to reproduce the issue on Buri v1.3. Environmental Variables: Device: Buri v1.1 mozRIL BuildID: 20140210041201 Gaia: c5cb252e5d1aa45d14f3a2ea182e73e2271e4496 Gecko: c29d165756ab Version: 18.0 v1.2-device.cfg This issue is also present on today's Master M-C build. Environmental Variables: Device: Buri Master M-C mozRIL BuildID: 20140210041201 Gaia: c273bd6525f7f295539592ce74d5e6b225d53be1 Gecko: ecf20a2484b6 Version: 18.0 v1.2-device.cfg
(In reply to Kartikaya Gupta (email:email@example.com) from comment #2) > If it still happens with APZC disabled then it's unrelated to APZC. > > That being said, if this changed recently, then it might be the result of > bug 965593 and is intentional (see comment 33 on that bug). I think this is a UX call. UX - Can you weigh in what you think the right behavior here is? Pulling the nom for now to discuss more.
blocking-b2g: 1.3? → ---
Flagging Casey to comment on expected scroll behavior here.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(kyee)
The scroll bars should be on top of the message and should fade-away/disappear when the scrolling stops.
Sounds like we need to backout whatever changed the behavior here then, as this goes against UX's recommendation.
blocking-b2g: --- → 1.3?
:tn, this may be a fallout from https://bugzilla.mozilla.org/show_bug.cgi?id=965593#c33, can you provide alternatives here since Bug 965593 is a blocker as well and a straight backout might leave that unfixed?
Let's wait for it to becomes 1.3+ because otherwise looking at 1.3? will slow down the work on 1.3+.
(In reply to Milan Sreckovic [:milan] from comment #10) > Let's wait for it to becomes 1.3+ because otherwise looking at 1.3? will > slow down the work on 1.3+. I don't think we should be waiting here if a backout is being requested here. A backout won't happen if we wait too long. We are going to end up blocking on this, as a 1.3 blocking UX impacted patch landed without a ur+, which violates our landing process established at a drivers level. This needs to be backed out.
Can we first verify that the backout will fix this problem? That was a hypothesis and not definitive. Secondly, what is ur+? When is it needed, and how do we obtain it?
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #12) > Can we first verify that the backout will fix this problem? That was a > hypothesis and not definitive. > > Secondly, what is ur+? When is it needed, and how do we obtain it? ur+ - ui-review+. It's needed if you are making any code changes that will change UX on the phone. It's usually set in the details of a patch.
1.3+ Milan please help with backout of this patch due to lack of ux review
blocking-b2g: 1.3? → 1.3+
This can also be fixed by taking out the z-index:1 in shared/style_unstable/lists.css for the |[data-type="list"] li| selector. That might affect other things though. Alternatively a change to the SMS app styles could also fix this.
For instance here is a patch to the SMS app that fixes the problem and that I don't think would have other side-effects.
I think we should just move on with the simple sms patch from kats. I'm taking the bug to see whether we have other places with the same issue.
Assignee: nobody → felash
Comment on attachment 8374916 [details] [diff] [review] Patch Review of attachment 8374916 [details] [diff] [review]: ----------------------------------------------------------------- r=me this works perfectly well, I'm landing this.
Attachment #8374916 - Flags: review+
master: 55e1331e403ecd6739aa75fba3c678ef620f8a29 thanks kats !
Assignee: felash → bugmail.mozilla
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Uplifted 55e1331e403ecd6739aa75fba3c678ef620f8a29 to: v1.3: 45db4d475d8fb155cb7944888e2a3dd0bafc7d73
I would like this to be re-tested on the next 1.3 nightly (one that contains the backout of bug 965593) to ensure that it hasn't regressed.
Verified fixed in v1.4. The scroll bar displays on top of the messages. Environmental Variables: Device: Buri v1.4 Moz RIL BuildID: 20140304040200 Gaia: 6df4533f14ec2645bb13d8a803a5151583ca13a8 Gecko: 529b86b92b1d Version: 30.0a1 Firmware Version: v1.2-device.cfg
Verified for v1.3T. I am unable to reproduce this issue on the latest v1.3T Tarako build: v1.3T Environmental Variables: Device: Tarako v1.3T MOZ RIL BuildID: 20140530014002 Gaia: e68858693b71d917c9c5ee7e215f7ceea04635f7 Gecko: 1945abae19ff Version: 28.1 Firmware Version: SP6821a-Gonk-4.0-5-12
You need to log in before you can comment on or make changes to this bug.