Closed
Bug 202620
Opened 21 years ago
Closed 18 years ago
Alarms fired do not draw adequate attention to themselves
Categories
(Calendar :: Alarms, defect)
Calendar
Alarms
Tracking
(Not tracked)
RESOLVED
FIXED
Sunbird 0.5
People
(Reporter: sl6si, Unassigned)
References
Details
Attachments
(1 file)
929 bytes,
patch
|
mattwillis
:
first-review+
dmosedale
:
second-review+
|
Details | Diff | Splinter Review |
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.
Comment 1•21 years ago
|
||
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.
Updated•21 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•21 years ago
|
||
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.
Comment 4•21 years ago
|
||
New contact from mikep@oeone.com to mostafah@oeone.com Filter on string OttawaMBA to get rid of these messages. Sorry for the spam.
Assignee: mikep → mostafah
Comment 5•21 years ago
|
||
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.
Comment 6•21 years ago
|
||
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 ...
Comment 8•20 years ago
|
||
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
Comment 9•19 years ago
|
||
*** Bug 267925 has been marked as a duplicate of this bug. ***
Comment 10•19 years ago
|
||
*** Bug 250137 has been marked as a duplicate of this bug. ***
Comment 11•19 years ago
|
||
*** Bug 264399 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
QA Contact: gurganbl → general
Comment 12•19 years ago
|
||
*** Bug 313645 has been marked as a duplicate of this bug. ***
Comment 13•19 years ago
|
||
*** Bug 321910 has been marked as a duplicate of this bug. ***
Comment 14•18 years ago
|
||
Will be the UI proposed by Bug 331323 a good place to configure the popup visibility (i.e. "flashing" or "on top")?
Comment 15•18 years ago
|
||
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Comment 16•18 years ago
|
||
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
Flags: blocking0.3?
Comment 17•18 years ago
|
||
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.
Flags: blocking0.3? → blocking0.3-
Comment 18•18 years ago
|
||
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.
Attachment #239420 -
Flags: second-review?(dmose)
Attachment #239420 -
Flags: first-review?(mattwillis)
Comment 19•18 years ago
|
||
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
Attachment #239420 -
Flags: first-review?(mattwillis) → first-review+
Comment 20•18 years ago
|
||
Comment on attachment 239420 [details] [diff] [review] call getAttention() if alarm is added to alarm dialog (checked in) r2=dmose
Attachment #239420 -
Flags: second-review?(dmose) → second-review+
Updated•18 years ago
|
Assignee: nobody → ssitter
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: [needs landing post 0.3]
Target Milestone: --- → Sunbird 0.5
Comment 21•18 years ago
|
||
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.
Attachment #239420 -
Attachment description: call getAttention() if alarm is added to alarm dialog → call getAttention() if alarm is added to alarm dialog (checked in)
Comment 22•18 years ago
|
||
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.
Whiteboard: [needs landing post 0.3]
Updated•18 years ago
|
Assignee: ssitter → nobody
Component: General → Alarms
QA Contact: general → alarms
Comment 23•18 years ago
|
||
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.
Comment 24•18 years ago
|
||
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.
Comment 25•18 years ago
|
||
(In reply to comment #23) +1 -> FIXED
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Summary: Alarms box fired but will not onto the top most window → Alarms fired do not draw adequate attention to themselves
Comment 28•17 years ago
|
||
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.
Comment 29•17 years ago
|
||
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?
Comment 30•17 years ago
|
||
(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.
You need to log in
before you can comment on or make changes to this bug.
Description
•