Closed Bug 981255 Opened 10 years ago Closed 10 years ago

[Sora][MMI]Alarm display abnormally when unlock secreen.

Categories

(Firefox OS Graveyard :: Gaia::Clock, defect, P1)

defect

Tracking

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

VERIFIED FIXED
1.4 S4 (28mar)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: sync-1, Assigned: mcav)

References

()

Details

(Keywords: regression, Whiteboard: [p=3])

Attachments

(4 files)

Firefox OS v1.3
 Mozilla build ID: 20140226004002
 
 regression: buri 1.1 is ok.
 
 Created an attachment (id=659355)
 clock
 
 DEFECT DESCRIPTION:
  Alarm& Contact& Calendar display abnormally when unlock secreen. 
 
  REPRODUCING PROCEDURES:
  1. Access "clock"-> Access "alarm"-> Create a new alarm-> Select "soonze"-> Don't select any snooze time-> Lock screen-> Unlock screen-> this interface display abnormally;--KO1
  2. Access "Calendar"-> Create a new event-> Must edit some words in "note" box and then show keyboard-> Lock screen-> Unlock screen-> This interface display abnormally;--KO2
  3. Access "Contact"-> Create a new contact-> Must edit some words in "Comment" box and then show keyboard-> Lock screen-> Unlock screen-> This interface display abnormally.--KO3
 
  EXPECTED BEHAVIOUR:
  All interfaces are normal as reference pic.
 
  CONTACT:
  021-61460666-7531.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
blocking-b2g: --- → 1.3?
Flags: needinfo?(vchen)
Attached image clock
Attached image contact
Attached image Calendar
Component: Gaia → Panning and Zooming
Keywords: regression
Product: Firefox OS → Core
Version: unspecified → 30 Branch
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 10 years ago
Flags: needinfo?(vchen)
Resolution: --- → DUPLICATE
But could you see the clock app screenshot? When I disable the APZC, I can still reproduce this issue agian. This is different.
Flags: needinfo?(jsmith)
(In reply to xiupinglong from comment #5)
> But could you see the clock app screenshot? When I disable the APZC, I can
> still reproduce this issue agian. This is different.

Did you restart the device after you disabled APZC?
Flags: needinfo?(jsmith)
(In reply to Jason Smith [:jsmith] from comment #6)
> (In reply to xiupinglong from comment #5)
> > But could you see the clock app screenshot? When I disable the APZC, I can
> > still reproduce this issue agian. This is different.
> 
> Did you restart the device after you disabled APZC?

Yes, I restart the device after disabled APZC, but the clock issue is still reproduced like the clock screenshot.
I think I'm going to wait for bug 980041's patch to land before I confirm this isn't the same bug. As far as I can tell, this problem still appears to be the same. I'm a bit surprised by the testing results above though.
Brogan - Can you check if this bug reproduces with APZC disabled on our builds? I want to confirm the above analysis that this is different than the dupe.
Flags: needinfo?(bzumwalt)
DISABLED APZC, then restarted Buri running 1.3. Clock/alarm issue reproduces, but contacts and calendar issues do not reproduce. All issues reproduce with APZC ENABLED.

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140311004003
Gaia: 6b1180917fa4af4e4b7e31b51fc06a4bbaa2ad0f
Gecko: 8976860941f2
Version: 28.0
Firmware Version: v1.2-device.cfg
Flags: needinfo?(bzumwalt)
Okay - sounds like the contacts & calendar issues are covered by the dupe, but the clock issue isn't. I'm going to reopen to track fixing this issue specific to the clock.
Status: RESOLVED → REOPENED
Component: Panning and Zooming → Gaia::Clock
Product: Core → Firefox OS
Resolution: DUPLICATE → ---
Summary: [Sora][MMI]Alarm& Contact& Calendar display abnormally when unlock secreen. → [Sora][MMI]Alarm display abnormally when unlock secreen.
Version: 30 Branch → unspecified
Hi,everyone.Is there any advance?
Nominated because it's blocking issue on our side.
blocking-b2g: --- → 1.3?
Marcus, can you confirm whether this is a blocker?
Flags: needinfo?(m)
(In reply to Candice Serran (:cserran) from comment #14)
> Marcus, can you confirm whether this is a blocker?

I don't think that's the right question to ask here. An operator ultimately holds the decision to block on something or not when we're in the IOT phase of a release, not a developer.
Jack

Is this blocking your IOT? Is this blocking cert?
Flags: needinfo?(liuyongming)
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(liuyongming)
Assignee: nobody → m
Attachment #8394974 - Flags: review?(mmedeiros)
Flags: needinfo?(m)
Target Milestone: --- → 1.4 S4 (28mar)
Comment on attachment 8394974 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17464

looks good to me. probably the easiest solution for now and should not cause side effects.
Attachment #8394974 - Flags: review?(mmedeiros) → review+
(In reply to Preeti Raghunath(:Preeti) from comment #16)
> Jack
> 
> Is this blocking your IOT? Is this blocking cert?

It is blocking IOT but not test case for cert.

Thanks.
Comment on attachment 8394974 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17464

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Unknown
[User impact] if declined: If users lock the phone after opening the picker for alarm sound or repeat, the Clock app will be non-functional upon unlock.
[Testing completed]: Manual verification.
[Risk to taking this patch] (and alternatives if risky): Very low.
[String changes made]: None.
Attachment #8394974 - Flags: approval-gaia-v1.3?(fabrice)
Attachment #8394974 - Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+
Landed in b540f206d01e2aa35dc01254e1ec9fc217e14464.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Comment on attachment 8394974 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17464

Please see the same approval request for 1.3 for comments.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:
Attachment #8394974 - Flags: approval-gaia-v1.4?
Reopening since it actually should land in 1.4 before marking as resolved.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Marcus Cavanaugh [:mcav] <mcav@mozilla.com> from comment #24)
> Reopening since it actually should land in 1.4 before marking as resolved.

Actually patches that land on trunk are typically marked as resolved. Something that is a 1.3+ blocker should automatically get an uplift to 1.4, so no need for an approval.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Attachment #8394974 - Flags: approval-gaia-v1.4?
Oh cool, good to know, thanks.
Yes, the ball dropping here was not landing on 1.4 when this was also landed on 1.3 and master. Please don't forget that in the future. Also, please set the status flags when uplifting patches.

v1.4: 9447dd9b7c8901c45e39b2f472820934de5e6e87
Will do, thanks Ryan.
Whiteboard: [p=3]
Status: RESOLVED → VERIFIED
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: