Closed Bug 987211 Opened 7 years ago Closed 7 years ago

[B2G][Dialer][Lockscreen] Time is not visible when receiving call while screen is locked

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

RESOLVED FIXED
1.4 S5 (11apr)
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- verified
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: bzumwalt, Assigned: drs)

References

Details

(Keywords: regression)

Attachments

(3 files, 2 obsolete files)

Attached image Screenshot
Description:
If user receives call while device screen is locked the time is not visible on screen. The clock doesn't appear on the screen where user is prompted to either answer or ignore call.

Repro Steps:
1) Updated Buri to BuildID: 20140324000202
2) Lock screen on device by short pressing power button
3) Receive call from second device

Actual:
Clock is not visible on lock screen when receiving call from second device.

Expected:
Clock is visible on lock screen when receiving call from second device.

Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140324000202
Gaia: 730670951e40b2317a167fcd07c398bb662d6e87
Gecko: a44f8b39c2c8
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 3/3, 100%
See attached: screenshot & logcat
Attached file Logcat (obsolete) —
Attached file Logcat - New
Console enabled and Gaia Debug Traces on in this one.
Attachment #8395736 - Attachment is obsolete: true
The issue doesn't reproduce on the latest v1.3 
- Clock is visible on lock screen when receiving call from second device

Device: Buri v1.3, Mozilla RIL
BuildID: 20140323164003
Gaia: 2e2e44886439c25c57583f51496c39ea9a6bee79
Gecko: 035e05fe78c1
Version: 28.0
Firmware Version: v1.2-device.cfg
QA Contact: jschmitt
blocking-b2g: --- → 1.4?
B2G Inbound:

Last Working:
Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140311114211
Gaia: d4089d85e307f13ae6a150c0bb76018c8ffc498d
Gecko: 11ed575e3613
Version: 30.0a1
Firmware Version: V1.2-device.cfg

First Broken:
Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140311115208
Gaia: 5aa7d6e424c46c2a9761ec85a016f39de3105d71
Gecko: 3d9501cda6f9
Version: 30.0a1
Firmware Version: V1.2-device.cfg

Last Working Gecko First Broken Gaia: Issue DOES repro
Gaia: 5aa7d6e424c46c2a9761ec85a016f39de3105d71
Gecko: 11ed575e3613

First Broken Gecko Last Working Gaia: Issue does NOT repro
Gaia: d4089d85e307f13ae6a150c0bb76018c8ffc498d
Gecko: 3d9501cda6f9

B2G Inbound Gaia Pushlog:

https://github.com/mozilla-b2g/gaia/compare/d4089d85e307f13ae6a150c0bb76018c8ffc498d...5aa7d6e424c46c2a9761ec85a016f39de3105d71

Tinderbox Gaia Pushlog:

https://github.com/mozilla-b2g/gaia/compare/3005269d4dcabcc7d27eaf72bda44a969873af8c...6c93da506e79bd7641f2cc0958b531ab84ceefe1
Regressing cause - bug 980984. Which means this is also present on 1.3T.
Blocks: 980984
blocking-b2g: 1.4? → 1.3T?
(In reply to Jason Smith [:jsmith] from comment #5)
> Regressing cause - bug 980984. Which means this is also present on 1.3T.

Note - the fix here is needed for 1.3T & 1.4. Looks like we don't have a flag for that though...
triage: regression. 1.3T+
1.3T+ should also mean it goes to 1.4 like 1.3+ right?
blocking-b2g: 1.3T? → 1.3T+
ni? Rik/Doug as Etienne's on PTO
Flags: needinfo?(drs+bugzilla)
Flags: needinfo?(anthony)
Assignee: nobody → drs+bugzilla
Flags: needinfo?(anthony)
Note - when this is fixed on trunk, please ask for Gaia 1.4 approval, as this would also block 1.4.
Whiteboard: [1.4-approval-needed]
Attached patch patch (obsolete) — Splinter Review
I narrowed it down to here, but this seems like a funnel into a pandora's box. I'm going to continue digging, but this seems to fix it for now.
Attachment #8396718 - Flags: feedback?(anthony)
Flags: needinfo?(drs+bugzilla)
Comment on attachment 8396718 [details] [diff] [review]
patch

Review of attachment 8396718 [details] [diff] [review]:
-----------------------------------------------------------------

This is not a code correctness issue but a race.

lazy_l10n callsback before l10n_date.js is loaded. So we need to fix lazy_l10n to not do that.
I think this race was not showing up before because we were doing some audio work that may have changed the order of things called.
Attachment #8396718 - Flags: feedback?(anthony) → feedback-
Based on the feedback and observation in comment 11.
Attachment #8396718 - Attachment is obsolete: true
Attachment #8397263 - Flags: review?(anthony)
Comment on attachment 8397263 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17665

From comment 11: "So we need to fix lazy_l10n to not do that."

The patch should live in lazy_l10n.
Attachment #8397263 - Flags: review?(anthony) → review-
Duplicate of this bug: 988170
Comment on attachment 8397263 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17665

Yep! Updated PR.
Attachment #8397263 - Flags: review- → review?(anthony)
Comment on attachment 8397263 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17665

We shouldn't have two places lazy load l10n_date. What about moving the lazy_load part inside onLocalized, like this?

      window.addEventListener('localized', function onLocalized() {
        window.removeEventListener('localized', onLocalized);
        loader.load('/shared/js/l10n_date.js', function cb() {
          finalize(callback);
        });
      });

Also, we need new tests. And because mock_lazy_loader is synchronous, I'd like to see a test that failed before that patch and works after.
Attachment #8397263 - Flags: review?(anthony) → review-
Attachment #8397263 - Flags: review- → review?(anthony)
Updated PR. This includes a test that used to fail and now doesn't.
Doug, seem like you are actively working on this so i will mark the target milestone to 1.4 S5. please change it if you think otherwise. Thanks
Target Milestone: --- → 1.4 S5 (11apr)
Comment on attachment 8397263 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17665

Please rename _waitForLoad to _waitForLoadAndDate. And fix the linter issue.
Attachment #8397263 - Flags: review?(anthony) → review+
https://github.com/mozilla-b2g/gaia/commit/bc5ccaaebe857c6127dbf95bbc8c32226c407a6b
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Comment on attachment 8397263 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17665

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 980894
[User impact] if declined: The clock will not be visible if the user receives a phone call while the screen is locked. There is no impact to the clock in other situations.
[Testing completed]: Tested on device by Anthony (rik) and I.
[Risk to taking this patch] (and alternatives if risky): Low.
[String changes made]: None.
Attachment #8397263 - Flags: approval-gaia-v1.4?(release-mgmt)
Is there a special process for requesting approval for 1.3T? My understanding is that if a bug is 1.3+ or 1.3T+, it gets automatic approval for either of those, but for 1.4 you need to ask for approval. comment 6 and comment 9 seem to conflict with each other.
Comment on attachment 8397263 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17665

approved for gaia-1.4 although rubber stamp
Attachment #8397263 - Flags: approval-gaia-v1.4?(release-mgmt) → approval-gaia-v1.4+
Following the STR from Comment 0, confirmed clock is visible on lock screen when receiving call from second device on latest 1.3Tarako build. 

Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140428014001
Gaia: 8895b180ed636069473703d0e7b73086989601ce
Gecko: 7caf4b5abfce
Version: 28.1
Firmware Version: sp6821a_gonk4.0_user.pac
You need to log in before you can comment on or make changes to this bug.