Closed Bug 845347 Opened 13 years ago Closed 12 years ago

alarm muted, and vibration only occurred after unlock

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::Clock
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(tracking-b2g:backlog, b2g18+ affected, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix)

Status:
RESOLVED WORKSFORME
Project Flags:
tracking-b2g backlog
Tracking Flags:
Tracking Status
b2g18 + affected
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- wontfix

People

(Reporter: dietrich, Assigned: alive)

References

Details

(Keywords: regression)

Attachments

(2 files)

logcat of alarm going off after waking up device
465.49 KB, text/plain
Details
no sound and vibration durring alarm goes off
3.90 KB, text/plain
Details
set alarm last night. didn't go off this morning. when i did get up, unlocked the phone and the alarm screen was visible, and phone immediately started vibrating.
note: i don't know if this is a recent regression or not. i haven't been using the phone as an alarm clock recently.
blocking-b2g: --- → tef?
Keywords: regression
So this looks like a lock screen issue - Joe can you re-assign this to the best dev to investigate? QA can you look into a regression window here and also please add testing the alarm clock to smoketests/daily testing?
Assignee: nobody → jcheng
blocking-b2g: tef? → tef+
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → affected
Keywords: qawanted, regressionwindow-wanted
QA Contact: jshih → jsmith
Ian, can you please look into this? thanks
Assignee: jcheng → iliu
Chris Barker - Can you help find someone from your team to get a regression window on this bug?
Flags: needinfo?(cbarker)
QA Contact: jsmith → jshih
I'm looking the issue as following experiment result. Build version: v1.0.1-unagi 20130226070204 Unplug power line. After I set an alarm and wait for notification, the alarm goes off normally with ringtone and vibration. Then, turn it off in 15 minutes. Even if I turn off screen, press volume up/down and touch other screen section without 'Close', 'Snooze' buttons during alarm goes off, the alarm still goes off with ringtone and vibration. I'll test it with more than 30 minutes. According our alarm spec, I should ring and vibrate 30 minutes. Dietrich, Could you please provide more information for issue? QA team, I would need your help to reproduce it. Thanks.
(In reply to Ian Liu [:ianliu] from comment #5) > I'll test it with more than 30 minutes. According our alarm spec, I should > ring and vibrate 30 minutes. I'm sorry to forget the spec about notifying user time. Correct the above comment. It should be 15 minutes. (https://github.com/mozilla-b2g/gaia/blob/master/apps/clock/js/onring.js#L102) So, I you don't handle the active alarm. We do not turn off the ringtone and vibration unit 15 minutes. Then, we'll leave the attention screen for user.
(In reply to Ian Liu [:ianliu] from comment #6) > So, I you don't handle the active alarm. We do not turn off the ringtone and ^ If > vibration unit 15 minutes. Then, we'll leave the attention screen for user. I have finished the test. Alarm goes off normally in 15 minutes. Then, it leave the attention screen and turn screen off by system idle service. And I turn the screen on, alarm don't vibrate for me.
QA Contact: jshih → atsai
QA Contact: atsai → fyen
This will likely require overnight testing. I've also tested setting the alarm for small periods of time and it works ok. I only see this bug when I set the alarm before bed, and check it in the morning, between 6 & 8 hours later.
The alarm has been working well for a long time (even for overnight testing). This must be a regression. Please do check this case with the following scenario, which can probably simulate the overnight testing without waiting long hours: 1. Unplug the USB/power line. 2. Kill the Clock App. 3. Turn off the screen. If this issue still happens, then I *guess* it's due to bug 836654.
> If this issue still happens, then I *guess* it's due to bug 836654. Specifically, you think the issue is that maybe we're not holding the CPU wake lock when we should be? I am totally OK if we revert the change to the alarm service (part 9, plus the change to SystemMessageManager.js in part 7), if you think that might fix this problem.
Looks like fyen is already looking this, so removing needs info on Chris Barker.
Flags: needinfo?(cbarker)
Only need regression window wanted on this.
Keywords: qawanted
I have Angela H working on this bug right now, she will have a regression window for you shortly.
I have Angela H working on this bug right now, she will have a regression window for you shortly.
(In reply to Gene Lian [:gene] from comment #9) > The alarm has been working well for a long time (even for overnight > testing). This must be a regression. Please do check this case with the > following scenario, which can probably simulate the overnight testing > without waiting long hours: > > 1. Unplug the USB/power line. > 2. Kill the Clock App. > 3. Turn off the screen. > > If this issue still happens, then I *guess* it's due to bug 836654. I reproduced with one shot using Unagi (with the reproduce step from comment 9). For some reason my Unagi is not showing build ID (this is another issue that will file bug seperately) but I just updated it OTA yesterday. I am on Beta channel. is this impacted by bug 836654?
Flags: needinfo?(justin.lebar+bug)
> I am on Beta channel. is this impacted by bug 836654? I have no idea what bits are on our beta channel, sorry. If you can get a git revision then you can run git log REV --grep 836654 . If the result is empty, REV does not contain bug 836654. Otherwise it does.
Flags: needinfo?(justin.lebar+bug)
not sure how comment 16 works so i have a logcat attached (i obtained the bugreport right after i turned on the screen and alarm started to go off but it should have gone off earlier). not sure if it helps anyone to look into this and i have just updated to the latest build over the air again. so from today's email [release] 20130225070200 is now promoted for channel beta i would believe the build is using the following changesets: gecko: 411fbca11fddd70dc29f10f51d65e1202be30375 gaia: 5691a16fff8e1403c75ed9d6f3a443b7e58198c6
I had no luck reproducing this bug nor finding the regression window. Last night I set alarms on 8 unagi devices w 8 dif builds, and all alarms went off at the set time. None of the phones were plugged in to any USB, I killed the clock app, and turned off the screen. hmmm i'm wondering what i did different.. I used the nightly builds.
I was not able to reproduce this morning :( It's recurring alarm, so will see again tomorrow.
Moving this to tracking so we can gather more data here.
blocking-b2g: tef+ → -
status-b2g18-v1.0.1: affected → wontfix
tracking-b2g18: --- → +
Clint - is this something A-Team could help with? Do you have the ability to set up tests that run over long intervals (12 hours, for example)? If not, can we get that set up? Finding the reproducible case here would go a long way towards a faster fix.
Flags: needinfo?(ctalbert)
> not sure how comment 16 works $ git clone git://git.mozilla.org/releases/gecko.git $ git show 411fbca11fddd7 [...] # Yep, the repository has that rev $ git log 411fbca11fddd7 --grep 836654 [...] # Yep, this rev contains bug 836654 As I said in comment 10, I'm happy if someone wants to back out some changes from bug 836654 to see if it fixes this issue. Just back out all of part 9, plus add back the line of code which was removed in part 7 in the SystemMessageManager. (You still want the new line of code as well. Order doesn't matter.)
Thanks Justin. I'm not sure it's worth doing that until we have reliable STR.
I was able to reproduce an issue where the clock wasn't sounding when it should. ## Environment : Gecko http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3867fca22e3d Gaia a41c7921fbf0839b894f277261dad4a22507f979 BuildID 20130228070201 Version 18.0 Unagi STR: 1. set alarm to 30 mins into future 2. go to settings -> Battery -> turn power save mode on 3. long tap on home button 4. quit out of clock app 5. launch email and browser 6. turn sound up all the way 7. let device sleep until the alarm should sound Expected: alarm sounds Actual: alarm does not sound, overlay appears, volume is up all the way.
Speaking with dietrich, he doesn't have power save mode on.
## Env: from pvtbuilds mozilla-b2g18-unagi-eng Device: Unagi Gaia: 64bec969635323b705f28f1aaaa11f99814ab8f9 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/a3f1ceead7ce BuildID 20130228070204 Version 18.0 ## Cannot reproduce. (power save mode on/off)
## Env: from pvtbuilds mozilla-b2g18_v1_0_1-unagi-eng Device: Unagi Gaia: a41c7921fbf0839b894f277261dad4a22507f979 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3867fca22e3d BuildID 20130228070201 Version 18.0 ## STR: 1. Settings > Barrery > enable Power save mode. 2. open clock app, set alarm to more than 30 mins into future. 3. long press home button, close clock app 4. turn off screen 5. wait until the alarm should sound ## Expected: - alarm sounds and vibrates ## Actual: - alarm doesn't sounds and vibrates, only show alarm page on screen.
Now we're talking! I think the next steps should be to determine whether this is a Gecko or a Gaia bug. Then we can bisect and find this sucker.
(In reply to Lukas Blakk [:lsblakk] from comment #22) > Clint - is this something A-Team could help with? Do you have the ability > to set up tests that run over long intervals (12 hours, for example)? If > not, can we get that set up? Finding the reproducible case here would go a > long way towards a faster fix. We are currently creating a long-running test suite. We don't have devices to run the suite on yet. Perhaps you and I should talk about recovering 10-20 unagis from the b2g test drivers. They are mostly tests of the form "do this set of actions for x iterations" and then fail or pass based on our stability. I don't know how we would ever automate an alarm test like this where we verify that the alarm sounded and vibrated though. That's a bit tough to do from inside the code.
Flags: needinfo?(ctalbert)
I saw this again this morning. Some more details: * power save mode is off * alarm is recurring monday-friday
Gecko http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3867fca22e3d Gaia a41c7921fbf0839b894f277261dad4a22507f979 BuildID 20130228070201 Version 18.0 I was able to reproduce with power save mode = off, 10 minutes into the future, alarm reoccuring monday - friday. No vibration no sound. Closed clock app, launched email that is setup w/ 2 email addresses, gallery and video. Purpose of launching the other apps is to run the pmem down and have different prioritizations after the clock. I will see if I can narrow the steps down as well as the regression range. I am reassigning to myself for QA to find the regression range.
QA Contact: fyen → nhirata.bugzilla
I might be wrong, but jlebar's patch had landed 3 days ago, so it should be in 27th build, but not in 26th build for v1.0.1 This would mean that it won't necessarily be affected by jlebar's patch since Deitrich reported it on the 26th ( https://github.com/mozilla-b2g/gaia/commit/04f8dc51734e77bd8409a2dc44f06ce0ac073287 ) I'll have to find a different regression window.
The builds in comment 27 and comment 28 both have my patches from bug 836654. It's still possible that backing that change out could fix things, however. You can do this in hg, but it's a bit easier in git. I'm using github.com/mozilla/mozilla-central here, but you could do the same thing with git.mozilla.org/releases/gecko.git. > $ git log --pretty=oneline origin/b2g18 --grep 840372 > 0104f493de759bcf4286f58994843e51edcebc5d Bug 840372 - Don't let valid regions grow beyond 8 rects. r=roc, a=tef+ So 0104f493 is the git commit corresponding to the hg/b2g18 commit. > $ git log --pretty=oneline 0104f493 --grep 836654 > 64eb0f540b985c29bab4c9a7f1d89d7201bfb448 Bug 836654 - Part 11: Follow-up for b2g18; fix compile errors. r/a=me > [...] So bug 836654 is in the b2g18 build. Now we do the same thing for b2g18_v1_0_1 (called "v1_0_1" in gecko.git, I think): > $ git log orgin/b2g18_v1_0_1 --grep 840372 > 68af0799bafae3d2cdd1cdb4a3b08453a37e5557 Bug 840372 - Don't let valid regions grow beyond 8 rects. r=roc, a=tef+ > > $ git log 68af0799b --grep 836654 > 177d1da0e1fc9cf4be66f955d081fdedf052e53c Bug 836654 - Part 11: Follow-up for b2g18; fix compile errors. r/a=me So bug 836654 is in the b2g18_v1_0_1 build. Are you guys able to bisect this? Is there anything I can do to help you understand exactly how to do so?
According Comment 32, I try to reproduce the issue step by step. But I still cannot reproduce it. Gecko d1f8b1579fa8c796310b1c0b5467ff7400d310cb Gaia f46906e594b613571bfcc8f146d60bffd42e5a5b BuildID 20130303070203 Version mozilla-b2g18_v1_0_1-unagi (https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18_v1_0_1-unagi/latest/sources.xml) I'll try to reproduce it by the same version in Comment 32.
(In reply to Ian Liu [:ianliu] from comment #36) > Created attachment 720531 [details] > no sound and vibration durring alarm goes off I can reproduce it with following build version according repo-steps of Comment 32. But not every time. from pvtbuilds mozilla-b2g18_v1_0_1-unagi Device: Unagi Gaia: a41c7921fbf0839b894f277261dad4a22507f979 Gecko: b3cd9efc36ce4556117c56ae11807d839023f603 BuildID 20130228070201 Version 18.0 And I cannot reproduce it with repo-steps of Comment 9. So, the issue could be not relative with bug 836654. We could try to find out what the different between build 20130228070201 and 20130303070203. In side of the symptom, we can see that attention screen is showing in correct time. It means that Clock app received system message normally. I suspect that the unexpected value of mozHidden we check during alarm goes off.(https://github.com/mozilla-b2g/gaia/blob/v1.0.1/apps/clock/js/onring.js#L53) If the value of mozHidden is "false" with more delay time, it will let Clock misunderstand to be a silent alarm. Does someone have any idea to evaluate the timing of mozHidden value changing from "true" to "false" during alarm goes off...? Or some patch make the timing change during these days.
I add some log to check the value of mozHidden. It is not our expected value... We got mozHidden='true' when the screen already turn on. ================================================================================== E/GeckoConsole( 988): Content JS LOG at app://clock.gaiamobile.org/js/onring.js:40 in rv_init: --> document.mozHidden = true E/GeckoConsole( 988): Content JS LOG at app://clock.gaiamobile.org/js/onring.js:54 in rv_checkMozHidden: in setTimeout 0 --> document.mozHidden = true ================================================================================== So, we got a silent alarm. Could QA team help to find out the regression?
> So, we got a silent alarm. Awesome! Can we change the alarm code so that it makes noise even if mozHidden == true? That might be an easier hack at this point. Can we check if the document becomes mozHidden == false after 10s or so? That will at least tell us whether this is a race or a permanent failure.
Sounds like one more visibility nightmare ;) I will talk to Ian tomorrow to see what I could do to this issue. Uh, the only thing I could figure out now is it might be the side effect of bug 828283.
That might mean that this bug has been around since 2013-01-28 16:10:28 PST ? I can start there to check for the regression window.
(In reply to Justin Lebar [:jlebar] from comment #39) > > So, we got a silent alarm. > > Awesome! > > Can we change the alarm code so that it makes noise even if mozHidden == > true? That might be an easier hack at this point. > > Can we check if the document becomes mozHidden == false after 10s or so? > That will at least tell us whether this is a race or a permanent failure. BTW I couldn't reproduce using 0228 build... I add a visibilitychange event listener in onring.js and find that it initially is hidden and never changes when alarm goes off ;/
(In reply to Justin Lebar [:jlebar] from comment #39) > Can we change the alarm code so that it makes noise even if mozHidden == > true? That might be an easier hack at this point. The reason why clock app checks visible state is to solve a case that call screen is upon alarm screen. If that happens, alarm shouldn't sounds nor vibrates because that would annoy the user who is on the call. We should discuss this online if possible. IMO this is API leakage and we don't have other way. :/
> I add a visibilitychange event listener in onring.js and find that it initially is hidden and never > changes when alarm goes off ;/ Okay, this is good! It means that probably someone is forgetting to call setVisible() on the frame. The alternative is a race condition, which is much harder to deal with...
See also bug 848006. For me the alarm does not sound if the phone is plugged in
I propose to use mozinterruptbegin/mozinterruptend handler to close/disable the alarm if necessary instead of check visibility here.
I still cannot reproduce this. For those who could reproduce please take this gaia: https://github.com/alivedise/gaia/tree/muted-alarm_v1-train to see what's the visibility state.
(In reply to Alive Kuo [:alive] (Life is a struggle.) from comment #46) > I propose to use mozinterruptbegin/mozinterruptend handler to close/disable > the alarm if necessary instead of check visibility here. I would prefer not to introduce a new DOM API to work around a bug that we don't even understand.
(In reply to Justin Lebar [:jlebar] from comment #48) > (In reply to Alive Kuo [:alive] (Life is a struggle.) from comment #46) > > I propose to use mozinterruptbegin/mozinterruptend handler to close/disable > > the alarm if necessary instead of check visibility here. > > I would prefer not to introduce a new DOM API to work around a bug that we > don't even understand. Fine, but it's not new API though. Another workaround is use a timer.. Justin, please see https://bugzilla.mozilla.org/show_bug.cgi?id=848006#c11 I have some log there. Still don't know what happens..
Ian, I will take this. Bug 848006 seems dupe of this but I am not sure.
Assignee: iliu → alive
Alive, Thanks for your help. And here are some information for you. I propose to use telephony call state to check a call during alarm goes off. It's a accurate way to know a call state. I have hacked it before... It should work to identify the state. Second priority, use mozinterruptbegin/mozinterruptend event for the issue. But there is a defect to leak some voice before received mozinterruptbegin event to pause audio tag. Even if alarm no need to sound, we still need to create a audio tag to listen the event. Since the mozHidden value is not reliable as before, I cannot trust the mozHidden value during alarm goes off(loaded, localized..). It will need more flag to control the correct state. Even we want to wait the mozHidden value in correct state. It will make the notification(sound, vibration) delay... (Alarm do not goes off in precisely time). It will also need to consider background/foreground/screen off state when received mozvisibilitychange event. We also need to pay attention for the event. Because some audio playback state control will change the visibility of a frame in Gecko side. I hear some issue about it from Dominic. Anyway, I will go back to help the issue when Bluetooth file transfer feature is ready.
> Since the mozHidden value is not reliable as before, I cannot trust the mozHidden value during alarm > goes off(loaded, localized..). But /why/ is mozHidden unreliable? I'm happy if we want to hack around this before we understand the answer, but I don't think we should ignore this question.
(In reply to Justin Lebar [:jlebar] (PTO 3/11-3/15, then GMT+9 until 3/24) from comment #52) > > Since the mozHidden value is not reliable as before, I cannot trust the mozHidden value during alarm > > goes off(loaded, localized..). > > But /why/ is mozHidden unreliable? I'm happy if we want to hack around this > before we understand the answer, but I don't think we should ignore this > question. I am also curious why alarm iframe is initially hidden "now" but got a visibilitychange event in about 300ms. :/
I believe this one and bug 848006 is dupe.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
It's a bit late, but I could not reproduce the bug on 2/27 build and I could repro it on the 2/28 build...
My phone was not plugged in. Re-opening to ensure this is different. Please close if your case also includes not-plugged-in. Also, I saw this again this morning, or a variation: Alarm worked fine, but after hitting snooze for the 4th time, the 5th alarm had no sound or vibration.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I've been seeing this too.
Saw silent-and-non-vibrating alarm screen again today. Phone was not plugged in.
:( (In reply to Dietrich Ayala (:dietrich) from comment #59) > Saw silent-and-non-vibrating alarm screen again today. Phone was not plugged > in. Dietrich, Is your build enabling adb? I am thinking to add some custom log for you in this case. I am not able to repro.
(In reply to Dietrich Ayala (:dietrich) from comment #59) > Saw silent-and-non-vibrating alarm screen again today. Phone was not plugged > in. Also, could you repro is it's plugged?
(In reply to Dietrich Ayala (:dietrich) from comment #59) > Saw silent-and-non-vibrating alarm screen again today. Phone was not plugged > in. I have a test with build version 20130312230202 last night. I cannot reproduce it. I also snooze alarm 5 times. And it works normally.
> Is your build enabling adb? > I am thinking to add some custom log for you in this case. I'm using the nightly channel builds. > Also, could you repro is it's plugged? yes, will plug in tonight before i go to sleep. > I have a test with build version 20130312230202 last night. I cannot > reproduce it. I also snooze alarm 5 times. And it works normally. I am glad more people don't like to wake up in the morning and can test this case ;)
QA told me nightly build is using v1-train. And patch of bug 848006 is uplifted to v1-train yesterday night per https://bugzilla.mozilla.org/show_bug.cgi?id=848006#c20 So I propose to stay tuned to see if this is resolved in next update. (In reply to Dietrich Ayala (:dietrich) from comment #63) > > Is your build enabling adb? > > I am thinking to add some custom log for you in this case. > > I'm using the nightly channel builds. > > > Also, could you repro is it's plugged? > > yes, will plug in tonight before i go to sleep. > > > I have a test with build version 20130312230202 last night. I cannot > > reproduce it. I also snooze alarm 5 times. And it works normally. > > I am glad more people don't like to wake up in the morning and can test this > case ;)
Form the file onring.js (clock.gaiamobile.org/js/onring.js) in clock module, you can see the init function as follow: init: function rv_init() { ...... if (!document.mozHidden) { //this is the path in screen on mode this.startAlarmNotification(); } else { // This path is used in screen off mode. var self = this; window.setTimeout(function rv_checkMozHidden() { if (!document.mozHidden) { // If mozHidden is true in init state, // it means that the incoming call happens before the alarm. // We should just put a "silent" alarm screen // underneath the oncall screen self.startAlarmNotification(); } }, 0); } ...... }, The mainly problem is that the parameter "document.mozHidden" is true even after a short wait of setTimeout Event. Because the load of all kinds pages and resources need more time than the function can give. Thus I think it is unsuitable to use setTimeout funtion to deal with the waiting time for loading. Alternatively, I use a "addEventListener" to deal with this problem. Its contents is as follow: document.addEventListener('mozvisibilitychange',function alarmNote(){ if (!document.mozHidden) { document.removeEventListener('mozvisibilitychange', alarmNote); self.startAlarmNotification(); } },false); When the visibility of the page is changing, the function "alarmNode" will be triggered. When the condition meets (that is document.mozHidden==false), the startAlarmNotification() will be triggered normally. I try a amount of times, and this bug is not appear again
(In reply to 田旻 from comment #65) Hello newcomer, I am pretty sure what you suggest has already been done in patch of bug 848006, isn't it? Could you check? Thanks.
(In reply to Alive Kuo [:alive] from comment #66) > (In reply to 田旻 from comment #65) > > Hello newcomer, > > I am pretty sure what you suggest has already been done in patch of bug > 848006, isn't it? Could you check? Thanks. Yes, I think you are right. We are nearly make the same change.
blocking-b2g: - → backlog
I'm marking this bug as resolved, under the following rationale: 1. The latest comments on this bug, from 10 months ago, indicate that this bug is either fixed or not reproducible; 2. Bug 898354 landed recently which addressed a number of issues including cases where the alarm appeared to never go off; 3. I can't reproduce this either; without a clear path to reproduce and/or more recent data, this bug isn't really actionable. If anyone can reproduce, feel free to reopen and/or provide more data.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → WORKSFORME
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: