Closed Bug 1069132 Opened 8 years ago Closed 8 years ago

[Lockscreen] Newer notifications are not actionable when music player widget is on with 320x480 devices


(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)

2.1 S6 (10oct)
blocking-b2g 2.1+
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- verified


(Reporter: mnjul, Assigned: gweng)



(Whiteboard: [p=1])


(3 files)

- With 320x480 devices, such as Buri, suppose we have music player widget on lockscreen.
- When the first notification comes in, it shows up on the lockscreen, and is actionable.
- When the second notification comes in, it replaces the first notification (which is specified in bug 1023500, and so is the fact that the notifications container is not scrollable)

Expected: the second notification is actionable.

Actual: the second notification is *not* actionable.

The same happens for the third, fourth, and all later notifications.
Greg, this is the bug I talked about earlier today. Could you have a check? Thanks.
Flags: needinfo?(gweng)
Can we mark as a regression, or ask our own QA first, to see if this is a regression? I would NI Gerry to give a check since we're co-work on another actionable notification bug.
Flags: needinfo?(gweng) → needinfo?(gchang)
Confirm this issue will happen in buri.
Gaia-Rev        3742913e11f69e789dcb0aa0dedf2e5572da0129
Build-ID        20140922185144
Version         34.0a2
Flags: needinfo?(gchang)
Hi Gerry, I found that I can't reproduce this on master, maybe my recent patch fixed it. Can you check it for master? And for 2.1, I think we can try it with one specific patch.
Flags: needinfo?(gchang)
As we discussed, the issue happened in the second notification not first one.
Flags: needinfo?(gchang)
Attached file Patch
Waiting CI. Set review.
Attachment #8494202 - Flags: review?(timdream)
Assignee: nobody → gweng
If this is not hurried, I can dig the root cause of the missing alignment. But if this become blocker (since user isn't able to tap to let it become actionable, which breaks the function completely), and the root cause is complex, I suggest we land the current patch as a short term solution. So I keep the patch and may submit another patch later.
Comment on attachment 8494202 [details] [review]

I think we should find out the reason of detail quirkiness of getBoundingClientRect() rather than accepting this patch -- unless this is 2.1+.
Attachment #8494202 - Flags: review?(timdream) → feedback+
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
blocking2.1+.  regression from bug 1043103
blocking-b2g: 2.1? → 2.1+
Blocks: 1077207
I have fired Bug 1077207 to solve this issue completely. Let's not block release and land the patch for v2.1.

But I don't know whether this should be a 2.1 only patch, or a common patch for master and v2.1 as we usually do.
Comment on attachment 8494202 [details] [review]

Set review again.
Attachment #8494202 - Flags: review?(timdream)
I would rebase it later.
Attached file Patch v2.1
Comment on attachment 8494202 [details] [review]

Let's land on both 2.1 and master.
Attachment #8494202 - Flags: review?(timdream) → review+
Gaia-Try is all green for the master patch:

So I rebase and land it now.

I would set v2.1 approval after I re-trigger the tests for v2.1 patch.
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [p=1]
Target Milestone: --- → 2.1 S6 (10oct)
Still failed at some totally irrelevant tests. I would push it again, and I want to submit the approval first.
Comment on attachment 8499285 [details] [review]
Patch v2.1

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Bug 1043103 implement the actionable LocKScreen but some unknown issues occurs so we have this bug
[User impact] if declined: No actionable notification on HVGA device
[Testing completed]: Gaia-Try failed at some irrelevant tests, I now push it again. I tested this patch manually on Buri device, and I can fix the test cass if the failed ones are really caused by this patch after I get the approval, since it usually takes long time to wait approval and Gaia-Try.
[Risk to taking this patch] (and alternatives if risky): No
[String changes made]: No
Attachment #8499285 - Flags: approval-gaia-v2.1?(fabrice)
Attachment #8499285 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
I would land the v2.1 patch since the failures on Gaia-Try seems are irrelevant. Someone submit a patch that is totally irrelevant to mine and it's only update some icons encountered the same errors:

And this is mine:

So I think if there are some real errors caused by my patch, it would be backed out.
Verified @ 
Gaia-Rev        7f738edf66b9298bceef8a4981d05d04fd04e540
Build-ID        20141006183012
Version         34.0a2
This issue is verified fixed on Buri 2.1 and Buri 2.2:

Buri 2.1

Environmental Variables:
Device: Buri 2.1
BuildID: 20141010001201
Gaia: 7ef2e1e59637a34ca4489c329b3bdee93df3ac6c
Gecko: e3d495eb85c6
Version: 34.0a2 (2.1) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Buri 2.2

Environmental Variables:
Device: Buri Master
BuildID: 20141010040202
Gaia: 1036b544b7e102592bd9fab95cd9317329ac1293
Gecko: 50b689feab5f
Version: 35.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

The second notification is actionable.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.