Closed Bug 970422 Opened 6 years ago Closed 6 years ago

[B2G][Messages] Scroll bar is displayed behind messages that have been sent

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T verified, b2g-v1.4 verified)

VERIFIED FIXED
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- verified
b2g-v1.4 --- verified

People

(Reporter: tnguyen, Assigned: kats)

References

Details

(Keywords: regression, verifyme)

Attachments

(2 files)

Attached image screenshot
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...
Flags: needinfo?(bugmail.mozilla)
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).
Flags: needinfo?(bugmail.mozilla)
Does this reproduce with APZC disabled? Does this reproduce on 1.1?
Keywords: qawanted
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
Keywords: qawanted
blocking-b2g: --- → 1.3?
(In reply to Kartikaya Gupta (email:kats@mozilla.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? → ---
Flags: needinfo?(firefoxos-ux-bugzilla)
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.
Flags: needinfo?(kyee)
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?
Flags: needinfo?(tnikkel)
Let's wait for it to becomes 1.3+ because otherwise looking at 1.3? will slow down the work on 1.3+.
Flags: needinfo?(tnikkel)
(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:kats@mozilla.com) 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+
Flags: needinfo?(milan)
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.
Attached patch PatchSplinter Review
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
Flags: needinfo?(milan)
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.
Keywords: qawanted
Keywords: qawantedverifyme
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
Status: RESOLVED → VERIFIED
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.