User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20021216 Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20021216 The alarm works fine if you are working with only a single opened window. But when you had opened several windows (e.g. when you are working with an excel spreadsheet, opened a explorer window and another Mozilla navigator sitting behind), when the alarm is triggered, an alarm box will be opened BUT it is opened behind all the other windows therefore not serving the purpose as the user will not see it. Reproducible: Always Steps to Reproduce: 1.set event alarm 2.open multiple windows using various application software 3. Actual Results: Alarm window opened but behind all the other windows Expected Results: Alarm window should opened onto the top most window to alert user.
Does not works for me. It pops up correctly. Could somebody confirm?
Yup, does not work for me either ... The alarm works fine if you are working with only a single opened window. But when you had opened several windows alarm will opened behind all the other windows. This bug is commonly known to all by now.
Windows 2000 SP4 Mozilla 1.3 Calendar 2003031913-cal I'm getting no alarm popup at all and no email notification either. Calendar preferences are set to Show an Alarm Box.
New contact from firstname.lastname@example.org to email@example.com Filter on string OttawaMBA to get rid of these messages. Sorry for the spam.
I also experience this problem. The alarm either needs to grab the input focus, or the alarm tab that pops up on the task bar needs to flash. Either would be acceptable to get attention.
I am seeing the same behaviour - the alarm does not show up on top of my other windows. It would help if the alarm in the task bar flashed (but it currently does not). This is on Windows 2000 SP 4.
environment: windows XP, sp1. yup, alarm triggered, but it can't appear on top of all other window. interesting stuff is that window WILL pop up after snooze ...
Confirmation that I'm still seeing the buggy behavior. (Alarm window opens, but does not receive focus: it just discreetly adds itself to the task bar.) Environment: Windows XP SP2 Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040809 Mozilla Sunbird/0.2a
*** Bug 267925 has been marked as a duplicate of this bug. ***
*** Bug 250137 has been marked as a duplicate of this bug. ***
*** Bug 264399 has been marked as a duplicate of this bug. ***
*** Bug 313645 has been marked as a duplicate of this bug. ***
*** Bug 321910 has been marked as a duplicate of this bug. ***
Will be the UI proposed by Bug 331323 a good place to configure the popup visibility (i.e. "flashing" or "on top")?
Reassigning all automatically assigned bugs from Mostafa to firstname.lastname@example.org Bugspam filter: TorontoMostafaMove
Hello, I recognized this behaviour also in the actual sunbird and also lightning builds. It would be really much better, if the alarm windows appears on top. Sunbird/0.3a2+ (20060713) Lightning 0.1+ (20060726) Thanks Thorsten
We would most definitely accept a good clean patch for this before 0.3, but I really can't forsee blocking the release on this, especially since this bug doesn't have an owner. There are some z-level bits in window management code that someone might want to play around with, if they're interested.
Created attachment 239420 [details] [diff] [review] call getAttention() if alarm is added to alarm dialog (checked in) http://developer.mozilla.org/en/docs/DOM:window.getAttention says: On Windows, the taskbar button for the window flashes, if this hasn't been disabled by the user. [ssitter: that works with Sunbird :-)] On Linux, the behaviour varies from window manager to window manager - some flash the taskbar button, others focus the window immediately. This may be configurable as well. On Macintosh, the icon in the upper right corner of the desktop flashes.
Comment on attachment 239420 [details] [diff] [review] call getAttention() if alarm is added to alarm dialog (checked in) I think that documentation is from the classic Mac OS days. getAttention() in this context causes the Dock icon to bounce. r1=lilmatt
Comment on attachment 239420 [details] [diff] [review] call getAttention() if alarm is added to alarm dialog (checked in) r2=dmose
Comment on attachment 239420 [details] [diff] [review] call getAttention() if alarm is added to alarm dialog (checked in) Patch checked in on MOZILLA_1_8_BRANCH and trunk.
I'm not marking this fixed because as I understand it, we're still not firing on top of all other windows (if we're not the front app). This just helps us draw attention to ourselves.
I say that we should _not_ fire on top of other windows. Users might click it away without being aware of it (like keep on typing, and press enter. window gone, because you just 'pressed' the button). Or they will close it right away, because they want to finish what they were doing. Calling getAttention is enough of a solution, in my opinion. It will call the users attention, without being too irritating.
mvl: that logic makes sense to me. As a user, I've been screwed by having something steal focus and typing unintended stuff enough times that this seems like a very worthwhile thing to avoid, and the getAttention behaviors seem like they ought to be sufficient.
(In reply to comment #23) +1 -> FIXED
Flashing in the taskbar is definitely not enough for me as my taskbar is usually hidden. Pop-up on top would work a lot better, and it definitely does not do it now when several windows are open. Again, could make it optional so others that feel differently can change it.
I have the opposite problem -- windows come up on top of the window I am typing into and capture input. Note that different window managers and different user preferences can determine the consequences of a window being 'on top'. For example many people set a preference (or use a default) that requiresthe mouse to be clicked in a window before typed text goes into that window. That usually also goes with bringing selected windows to the top. I intensely dislike that because I often wish to type in part of a window while another window is visible and covering the rest of that window, e.g. editing a program while looking at a bug-report or documentation. So I set text input to follow the mouse: i.e. keyboard input goes to any window that the mouse happens to be in. So if a calendar alarm comes up where the mouse pointer happens to be and I am in the middle of typing, the input goes directly to to the alarm notification, and this can in some cases dismiss an alarm before I have had time to see what it is. That is very bad behaviour in something that pops up without being explicitly invoked by the user. So the alarm popup should not accept any keyboard input until after the user has either clicked on a specific button labelled something like 'accept keyboard input' or else the user has pressed some very unusual (user-specified) combination of keys, e.g. ctrl+alt+F1? Should I make this a different bug report, or should its fix be part of the fix to this bug?
(In reply to comment #29) > Should I make this a different bug report, or should its fix be part of the fix > to this bug? This bug has already been resolved since end of last year. Please open a new bug, and bring only one issue up per bug report.