maemo.org Bugzilla – Bug 8115
Having a modal dialog in background, Alarm dialog blocks entire UI => battery removal
Last modified: 2010-04-16 18:50:05 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: Maemo 5 Version: 2.2009.51-1 EXACT STEPS LEADING TO PROBLEM: 1. Simply create an alarm (for example for 8:00 clock in the morning) 2. Switch the device to offline mode (wifi and gprs off) 3. Go to bed and have a nice sleep until the alarm rings in the morning EXPECTED OUTCOME: The alarm rings at 8:00 clock and I can either stop or snooze the alarm by pressing the relevant buttons on the popup window. The window disappears afterwards and the normal desktop is ready to work with. ACTUAL OUTCOME: The user interface is simply dead. Pressing the buttons does not stop/snooze the alarm. I waited an hour that the popup window disappears. No reaction of the phone. I have to remove the battery to get rid of this bug :(. REPRODUCIBILITY: I have tested it twice and 2 times the same effect. EXTRA SOFTWARE INSTALLED: Only software from the nokia repository, the ovi store and from maemo extra. NOTHING from maemo devel or testing. OTHER COMMENTS: The phone is still running. If I open the camera lens then you can see the camera application is starting up in the background. If the screen is locked and I press the power button the unlock screen appears and the GUI reacts on the unlocking action. But afterwards the alarm popup window blocks the UI. Pressing the power button (aka on/off button) shows no action. The power menu does not appear. Possibly it has something to do with a deep sleep mode of the phone. Because Wifi and GSM are off the phone can really sleep during the night. Alarm does not block the UI if the phone is in active state (during the day). I have not tested this scenario on an earlier version. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Does toggling the unlock slider once or twice have any effect?
No. I have tried a lot of things during the one hour waiting to get the device out of this state. I have attempted to press all available buttons in a random order to get out of this UI freeze. I have done another test. If I leave the GSM module on during night the UI freeze does not appear. Moreover if I go to offline mode and the alarm appears within some minutes the UI is ok too. So it seems that it has something to do with a very long sleep phase of the phone. I think that a lot of software components are switched of including the X server (aka graphics card). And the alarm application seems to grab the X server. There seems to be a race condition between the waking up of the graphics subsystem and the grabbing of the X server or something like that. But I do not know the architecture of the whole maemo platform.
I'd love to see a second confirmation for this. I tried this with Offline Mode in internal version 2010.03-1 and cannot reproduce - the Desktop works after stopping the alarm, but that was for an alarm 3 minutes after creating it.
Ok. I will try to reproduce the bug this night. I set up an alarm for tomorrow in the morning and switch the phone to offline mode this evening. I will report my results tomorrow. If I trigger the event some minutes later and go to offline mode the alarm UI works also correctly on my phone. Please remember: I have closed all applications which show up on the dashboard otherwise. Because if you have applications open and running there is always activity in the system and therefore the effect does not appear (that's my personal view of course).
Here's your second confirmation, Andre. I have been using my new N900 since mid. december 2009 without any problems until 2 weeks ago where, at some point, I had the first occurence of this critical problem/bug. So is this related to some Maemo update I've accepted ? I don't know, but I know I've been updating my OS every time there was an update available. ACTUAL OUTCOME : I set a calendar event with an alarm (I've tried the "0 min, 5 min. and 30 min) options. If the device is sleeping when the alarm fires, the whole interface stops responding visually, but the haptic feedback system continues to "know that I'm pushing here and there on the screen". But none of the "repeat", "details" or "stop" button would work. I'm stuck on the "alarm" page until I remove the battery ! However, the device is not frozen completely... I can use the side lock button to put it back to sleep. After that, I can push the top button to unlock the device (and the ball-sliding unlock operation works as expected!). As stated earlier in first comment, if I slide open the camera cover, I can see in the background (behind the persistent "alarm" dialog) that the camera is initializing, but I don't see any live image from the camera... it's just black. I can also push the volume up and down buttons and the visuals showing my current volume kick in as expected (but I don't know if the volume is actually properly setup because I don't have any music playing in this state). in this "stuck alarm" state, hitting any keyboard key doesn't seem to have any effect of any kind. EXPECTED OUTCOME: same as explained in bug description. REPRODUCIBILITY: it's not trivial. After removing the battery and powering up, it seems that I can fire some event alarms without any problem.... but at some point, the bug happens. I'll try to investigate a little bit more today to get a nice "STEPS TO REPRODUCE" with actual version of my OS and stuff.
The effect still occurs. But the good news is that I have found out the reason for this misbehaviour. And even better, there exists a short way to easy reproduce the error. Do the following: 1. Go to Settings -> Internet connections: Select for "automatically connect" the value "always ask" (I translated this from the german version!) 2. Switch the phone to offline mode. 3. Set an alarm which is 3 minutes later (or whatever time you like) 4. Start the browser and enter any web address 5. A modal popup window appears: It asks you if the offline mode should be deactivated. DO NOT PRESS ANY BUTTON! 6. Wait until the alarm arrives 7. And voila, the UI is frozen Analysis: The problem here is that you get 2 modal popup windows. The "offline mode" one has grabbed the focus/keyboard/mouse because it is the first one which appeared. The second one (alarm notification) overlays the first one but the second one can not get the mouse input because it is already reserved by the first one. One solution is to inherit the focus/input to the last appeared modal window by the UI subsystem. Of course you can also queue these events and have a separate subsystem for such interactions. Hope this helps to solve the problem.
Another confirmation. First occurred on 2009-01-18. I see all the symptoms the other two posters have reported. When it first occurred I solved the lock-up by removing the battery. This morning I think it was cleared after switching to phone mode and then ensuring every app was closed. OS version is as stated 2-2009.51-1.203-2
I have forgotton another bad symptom of the "offline mode" popup window. It drains a lot of power out of the battery if it happens in the night. I started my attempt with an almost full battery. And 8 hours later the battery is almost completely empty :(. But I thought that going into offline mode during the night is good because it is the best way to save power. But the reality is a little bit different. I have forgotton another bad symptom of the "offline mode" popup window. It drains a lot of power out of the battery if it happens in the night. I started my attempt with an almost full battery. And 8 hours later the battery is almost completely empty :(. But I thought that going into offline mode during the night is good because it is the best way to save power. But the reality is a little bit different.
*** Bug 8244 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > There exists a short way to easy reproduce the error. Awesome. Thanks so much for the investigations here, I can reproduce it too.
Do you have the RSS feed reader widget on your desktop? Bug 8002 might be the root of this problem, while comment 6 is a great way to see its outcome.
confirmed. I have the RSS feed reader on my desktop.
Yes. I have also the RSS feed reader on my desktop.
(In reply to comment #13) > Yes. I have also the RSS feed reader on my desktop. > So the best way at the moment is to deactivate the automatic update of the RSS feed widget - it is not working as expected....
(In reply to comment #14) > (In reply to comment #13) > > Yes. I have also the RSS feed reader on my desktop. > > > > So the best way at the moment is to deactivate the automatic update of the RSS > feed widget - it is not working as expected.... > This will avoid the described problem...
Confirmed. robiwan's solution of deactivating the RSS Reader Widget on the desktop last night worked. Alarm fired okay and I could stop it without problem. Thanks guys.
(In reply to comment #16) > Confirmed. > robiwan's solution of deactivating the RSS Reader Widget on the desktop last > night worked. Alarm fired okay and I could stop it without problem. > Thanks guys. > Deactivating the whole widget is NOT neccessary - it is enough to deactivate the auto update setting....
(In reply to comment #17) > (In reply to comment #16) > > Confirmed. > > robiwan's solution of deactivating the RSS Reader Widget on the desktop last > > night worked. Alarm fired okay and I could stop it without problem. > > Thanks guys. > > > > Deactivating the whole widget is NOT neccessary - it is enough to deactivate > the auto update setting.... > AND - i hope auto update will work again in the next release - because deactivating it is only a workaround - not a fix
I can confirm this problem. Alarm sound goes on and you can hear the touchpad clicks (when enabled) but nothing happens. My workaround is I put the phone in portrait mode to start the phone app. This seems to push the alarm clock away...
I've just got this problem too, and I'm quite sure that what happened is what has been described in comment #6.
And I don't know what happened, but I didn't have to remove the battery: after removing the battery cover, I didn't manage to do it with my fingers, but then I noticed that I had the message saying if I want to leave offline mode, and I could answer.
(In reply to comment #11) > Do you have the RSS feed reader widget on your desktop? > Bug 8002 might be the root of this problem, while comment 6 is a great way to > see its outcome. Yep, RSS feed reader here too. For silencing the alarm, flipping the phone face down still works ok and after that you can get to the "offline" prompt below.
I'm not sure. I think I had this bug this morning. I woke up, snooze the alarm. Watched on my EMails, saw a Update from maemo extras (VNC), I installed it and in the moment the update finished and the complete message appeared the alarm appears and the UI freezed. I was not able to cancel it or shutdown the phone. I had to remove the battery. I hope this has something to do with this bug and could help. But I guess, the yellow message that appears after a installation prozess is not a modal dialog.
This has been fixed in package osso-systemui-modechange 0.3.5+0m5 which is part of the internal build version 2010.05-2 (Note: 2009/2010 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Created an attachment (id=2323) [details] Screenshot of Battery-Eye
Yesterday I also encountered this bug, exactly as described here. Phone in offline mode -> alarm -> unable to tap any button. Only the lock-slider and powerbutton-swipe responded. When i finally wanted to remove the battery, the phone asked if i wanted to exit offline. I was also using the RSS widget. I'm running PR 1.1.1 which apparently comes with osso-systemui-modechange 0.3.4+0m5. Why isn't the version with the bugfix included??? It was fixed before PR1.1.1 was released... :/ This morning i had a similar issue, but now i really had to pull out the battery: EXACT STEPS LEADING TO PROBLEM: 1. Set the alarm clock at 8:25 2. Activate the silent profile (so i can sleep without being called) 3. Lock the phone by pressing the powerbutton twice 4. Leave Mauku (2beta4) running, so it can update during the night (i simply leave it open during the night instead of using the mauku-widget, which i don't really like) 5. I also had 1 other program open, but i forgot which one 6. Leave the phone in Online mode (otherwise there would be no point in leaving Mauku running) EXPECTED OUTCOME: In the morning at 8:25 i wake up by the sounds of the alarm, I tap 'Stop' and have shower. ACTUAL OUTCOME: At 8:28 i wake up, because i hear my phone is buzzing. But NO alarm sound is being played and nothing is displayed on the screen (it's entirely black). I try to stop the buzzing, but the phone does not respond. I can't even get it to display something on the screen. The slide-button and powerbutton did not have any effect at all. In the end i removed the battery to stop the buzzing (which had been going on for more than 6 minutes by then) This may be completely unrelated, but when i had a look at Battery-Eye this morning i noticed a rather strange graph (see attachment). I went to sleep at 0:30 and attached the phone to the charger. However the battery kept draining instead of charging until around 4:00 in the morning until it was completely empty and then after one hour it finally started to charge. It was only charged 30 minutes before the alarm went of...
(In reply to comment #26) > Why isn't the version with the bugfix included??? It was fixed > before PR1.1.1 was released... :/ Please check your statements first. Comment 24 clearly says that this was fixed in year 2010, week 05. PR1.1.1 was packaged in year 2010, week 02 (3.2010.02-8). Anyway, offtopic here. This bug is fixed internally, no further comments needed.
*** Bug 9419 has been marked as a duplicate of this bug. ***
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).
*** Bug 9570 has been marked as a duplicate of this bug. ***
*** Bug 9883 has been marked as a duplicate of this bug. ***
*** Bug 9941 has been marked as a duplicate of this bug. ***