71222 - popup dialogues that demand input lock browser input in other windows

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Josh Steiner]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1) Gecko/20010306
BuildID:    2001030605

I use IMP web mail, when it gets new mail it pops up a little "You have new
mail.  <ok>" dialogue.  it often happends that that dialogue gets covered up by
another moz window, i dont realise the dialogue exists and is waiting for me,
and i can't click on links in the top browser window

Reproducible: Always
Steps to Reproduce:
1. Popup a dialogue waiting on entry.
2. go to another moz window
3. try to cliock a link and see that it wont go until you close the dialogue...

Comment 1

[Boris Zbarsky [:bzbarsky]]

Similar to bug 65521, but that one is Linux-only....

assigning to XP Toolkit: Widgets

Comment 2

[John Morrison]

I don't get how to reproduce this. On windows, an alert (or prompt/confirm) is 
window modal, not application modal, and while an alert is up for one window
(blocking its use), another browser window is fully usable including clicking
on links. 

Can you attach a screenshot of what the dialog looks like, and/or put together 
a testcase of the code (js/html) that spins up that dialog. Thanks.

Comment 3

[Josh Steiner]

I have just tested it on both win 98 and win 2k.  It happens consistantly for
me.  Try this:

1) open 2 windows, one that has a visible link on it (yahoo.com)
2) in the second, go to a bogus URL (askjdlfasd.com) ... moz should popup a
dialogue saying it can't find that address
3) go back to the yahoo page without clicking ok, you shouldnt be able to click
any links

Comment 4

[John Morrison]

Okay, that dialog, spun up from necko is application-modal. 

Comment 5

[Peter Trudelle]

Then you shouldn't be able to switch to another window, right?  ->danm

Comment 6

[John Morrison]

(Uh, duh.) Right, it's /not/ application-modal, it's window-modal, but it 
is blocking events from the other window being processed. 

Comment 7

[John Morrison]

*** Bug 54567 has been marked as a duplicate of this bug. ***

Comment 8

[Dan M]

nsWebShells cache the current active event queue in their Create method. That's 
the queue onto which is placed the event to process a clicked link. That's also 
the queue that's stalled when any modal window is up. 'tis better to place the 
clicked link event on the current active event queue, not a cached one.

Comment 9

[Dan M]

Attachment: place clicked-link event on current active event queue

Comment 10

[rpotts (gone)]

Looks good to me.  (sr=rpotts)

The only change I'd make is to add an if-test for eventQueue after the 
NS_ASSERTION just in case :-)

+  aHandler->GetEventQueue(getter_AddRefs(eventQueue));
+  NS_ASSERTION(eventQueue, "no event queue");
   eventQueue->PostEvent(this);

Comment 11

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 12

[Dan M]

patch is in

Comment 13

[John Morrison]

verified fixed on win32; a necko modal warning dialog only blocks interaction 
with the parent window, not with other open windows. (Linux has bug 65521 in 
the way, and the Mac is just not into window-modality).