Closed Bug 1061127 Opened 10 years ago Closed 10 years ago

[Lockscreen] The time of notification in lockscreen keeps display "just now" as time elapsed

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

VERIFIED FIXED
2.1 S4 (12sep)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- fixed

People

(Reporter: gchang, Assigned: gmarty)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(2 files)

### Steps:
1. Generate multiple notifications in lockscreen. ex: create multiple screenshots.
   In attachment, the screenshots were created in 4:24
2. Wait for more than 10 minutes. 
3. In 4:37, the time of the notifications are all "just now".

### Expected:
1. The time should be like "10m ago"


### Actual:
1. The time doesn't change.

### Reproduce rate
always

### Version:
Device    flame
Gaia      2be78d83a760fa3b9638fe51c266b442d14597f1
Gecko     https://hg.mozilla.org/mozilla-central/rev/1db35d2c9a2f
BuildID   20140831160203
Version   34.0a1
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Triage: blocker
blocking-b2g: 2.1? → 2.1+
QA Whiteboard: [COM=Gaia::System::Lockscreen]
That was working, until recently ... Let's get regression window.
Confirmed regression. Updating tracking flags from branch checking results on Flame.
QA Contact: pcheng
b2g inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140829112301
Gaia: c05ee27dd1f39e0f1cceb8bc7706e20f297cd9df
Gecko: 7d956b954dd7
Version: 34.0a1
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20140829113200
Gaia: 4419091ae760328a52606920e335331a16fcb448
Gecko: 3748d4065959
Version: 34.0a1
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken gecko & Last working gaia - issue does NOT repro
Gaia: c05ee27dd1f39e0f1cceb8bc7706e20f297cd9df
Gecko: 3748d4065959

First broken gaia & Last working gecko - issue DOES repro
Gaia: 4419091ae760328a52606920e335331a16fcb448
Gecko: 7d956b954dd7

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/c05ee27dd1f39e0f1cceb8bc7706e20f297cd9df...4419091ae760328a52606920e335331a16fcb448

Possibly caused by Bug 1038723 ?
QA Whiteboard: [COM=Gaia::System::Lockscreen] → [COM=Gaia::System::Lockscreen][QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Possibly caused by Bug 1038723 ? can you take a look ?
QA Whiteboard: [COM=Gaia::System::Lockscreen][QAnalyst-Triage?] → [COM=Gaia::System::Lockscreen][QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(gmarty)
This regression is caused by this line:
https://github.com/mozilla-b2g/gaia/pull/23572/files#diff-9a74bae315146783bc7b24d5d7302a95L331

Reverting the selector to its previous value will probably fix it.
This is something I discussed with Etienne, but I didn't know it would have an impact outside of the utility tray.
Flags: needinfo?(gmarty)
Set the regressed bug as blocked.

:gmarty, could you address the regression?
Blocks: 1038723
Flags: needinfo?(gmarty)
Whiteboard: [systemsfe]
Attached file Github PR
Hey Tim, here is the fix that revert to the original behaviour.
Attachment #8486429 - Flags: review?(timdream)
Flags: needinfo?(gmarty)
Assignee: nobody → gmarty
Comment on attachment 8486429 [details] [review]
Github PR

I think this is a valid fix for v2.1 but I don't know if this affects on-going lock screen work -- we should really decouple the DOM between two, but maybe not in this bug.
Attachment #8486429 - Flags: review?(timdream)
Attachment #8486429 - Flags: review+
Attachment #8486429 - Flags: feedback?(gweng)
Thanks Tim for the review. The scope of this blocker is to restore the functionality.
Any refactoring should be done in a separate bug.

I'll merge and close it for now, but keep the feedback? open.
Fixed in https://github.com/mozilla-b2g/gaia/commit/baa0a5bbf49904604543e83460ee683142c68867
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Please request Gaia v2.1 approval on this when you get a chance.
Flags: needinfo?(gmarty)
Target Milestone: --- → 2.1 S4 (12sep)
Comment on attachment 8486429 [details] [review]
Github PR

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Regression caused by Bug 1038723
[User impact] if declined: the notifications on the lockscreen won't get updated.
[Testing completed]: yes
[Risk to taking this patch] (and alternatives if risky): Very low
[String changes made]: None
Attachment #8486429 - Flags: approval-gaia-v2.1?(bbajaj)
Flags: needinfo?(gmarty)
Attachment #8486429 - Flags: approval-gaia-v2.1?(bbajaj) → approval-gaia-v2.1+
Attachment #8486429 - Flags: feedback?(gweng)
After I finally have time to clear my Bugzilla queue, I've realize the patch select *all* DOM with the class:

    var timestamps = document.getElementsByClassName('timestamp');

I think this is very improper. We should never assume the class only used by us, in the domain of Notifications!
I think we need to fire another bug to fix it. No matter whether it's a legacy behavior or not, it's just not correct.
I've fixed this in LockScreen frame, while I'm manually rebasing it.
Verified @
Gaia      e731a63484c532168f4de6dc1eeb4c6612ad73a9
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/868cc9e5e32a
BuildID   20140915160206
Version   34.0a2
Status: RESOLVED → VERIFIED
Verified per comment 20 against 2.1 branch.   Gerry, dont forget when you verify on branch, you need to set the flag:  status-b2g-2.1 = "verified"   Marking status from RESOLVED => VERIFIED only gets you verification on trunk.
Flags: needinfo?(gchang)
Hi Tony, 
Thanks for your reminder.
Flags: needinfo?(gchang)
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: