Situation: - 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.

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.

Confirm this issue will happen in buri. Gaia-Rev 3742913e11f69e789dcb0aa0dedf2e5572da0129 Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/df42b05782aa Build-ID 20140922185144 Version 34.0a2

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.

As we discussed, the issue happened in the second notification not first one.

Waiting CI. Set review.

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] Patch I think we should find out the reason of detail quirkiness of getBoundingClientRect() rather than accepting this patch -- unless this is 2.1+.

[Blocking Requested - why for this release]:

blocking2.1+. regression from bug 1043103

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] Patch Set review again.

I would rebase it later.

Comment on attachment 8494202 [details] Patch Let's land on both 2.1 and master.

Gaia-Try is all green for the master patch: https://tbpl.mozilla.org/?rev=14ee1c60289670fa5349612d301649d091d373cd&tree=Gaia-Try So I rebase and land it now.

master: https://github.com/mozilla-b2g/gaia/commit/5993c5953c7e4ffc6f424f9b8174566256c9ba02 I would set v2.1 approval after I re-trigger the tests for v2.1 patch.

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] 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

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: https://tbpl.mozilla.org/?rev=5c93d2f1787c8f8d79af109a2976ba87f2e166aa&tree=Gaia-Try And this is mine: https://tbpl.mozilla.org/?rev=504b95ed7824cec1a1396ee5b4415b6a913cff84&tree=Gaia-Try So I think if there are some real errors caused by my patch, it would be backed out.

v2.1: https://github.com/mozilla-b2g/gaia/commit/7f738edf66b9298bceef8a4981d05d04fd04e540

Verified @ Gaia-Rev 7f738edf66b9298bceef8a4981d05d04fd04e540 Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/d034c79c3304 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.