Alarms fired do not draw adequate attention to themselves

RESOLVED FIXED in Sunbird 0.5

Status

Calendar
Alarms
--
major
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: Mike, Unassigned)

Tracking

unspecified
Sunbird 0.5

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

14 years ago
Does not works for me. It pops up correctly. Could somebody confirm?
(Reporter)

Comment 2

14 years ago
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

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

14 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

14 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

14 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

14 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.

Comment 7

14 years ago
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 ...

Updated

13 years ago
Blocks: 250137

Comment 8

13 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

12 years ago
*** Bug 267925 has been marked as a duplicate of this bug. ***

Comment 10

12 years ago
*** Bug 250137 has been marked as a duplicate of this bug. ***

Comment 11

12 years ago
*** Bug 264399 has been marked as a duplicate of this bug. ***

Updated

12 years ago
QA Contact: gurganbl → general

Comment 12

12 years ago
*** Bug 313645 has been marked as a duplicate of this bug. ***

Comment 13

12 years ago
*** Bug 321910 has been marked as a duplicate of this bug. ***

Comment 14

11 years ago
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 nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody

Comment 16

11 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

11 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

11 years ago
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.
Attachment #239420 - Flags: second-review?(dmose)
Attachment #239420 - Flags: first-review?(mattwillis)
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 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+
Assignee: nobody → ssitter
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: [needs landing post 0.3]
Target Milestone: --- → Sunbird 0.5
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)
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

11 years ago
Assignee: ssitter → nobody
Component: General → Alarms
QA Contact: general → alarms
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
Status: NEW → RESOLVED
Last Resolved: 11 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

Updated

10 years ago
Duplicate of this bug: 377806

Updated

10 years ago
Duplicate of this bug: 388073

Comment 28

10 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

10 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?
(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.