56677 - window->OpenDialog not behaving in an XP fashion.

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Javier Delgadillo]

In psm-glue, we used parentWindow->OpenDialog to open dialog boxes that PSM 
brings up.  When calling OpenDialog and passing in the "modal" flag to the 
method, Linux often hangs and/or brings up a child window that does not process 
mouse events.

In psm-glue, we will try working around this problem by calling 
parentWindow->Open and modifying the parameter string to one that works on 
Linux.

Comment 1

[Johnny Stenback (:jst)]

Modality problem, reassigning to danm.

Comment 2

[John Unruh]

This appears to be working on Linux now.

Comment 3

[Javier Delgadillo]

It works because I added code to open the window differently on Linux as opposed 
to Windows.

Comment 4

[Dan M]

It works on Linux because you're no longer opening nonmodal windows on top of 
modal ones on that platform; an explanation I find myself repeating surprisingly 
often. I'm beginning to wonder if it's me that's crazy.

This bug remains open instead of being closed invalid because the frequency with 
which people try to shoot themselves in the foot like this begs some sort of 
automatic workaround.

Comment 5

[Brendan Eich [:brendan]]

Automatic workaround, or error return.  Why should non-modal on top of modal
work, anyway?

/be

Comment 6

[Dan M]

  Well, because preferences and security dialogs are doing it, hearing my 
protestations about it, and filing bugs against me when it doesn't work. We're a 
toolkit after all; maybe our response should be more civil than a broken window. 
I had in mind detecting the situation (not quite sure how yet) and simply making 
the new non-modal child window, modal.
  I hadn't thought about returning an error. Either should be a similar amount of 
trouble; the difficulty is knowing that the parent is modal at the right place.

Comment 7

[Javier Delgadillo]

I wasn't aware that child windows of modal windows didn't necessarily inherit 
modality.  My mistake.

Is there someway we can modify the JavaScript (all the windows are open via 
window.open from within the security advisor) to force modality?

Comment 8

[Dan M]

That's just it; this situation seems to surprise a lot of people, so it wants 
something done about it. I could make children of modal windows inherit the 
modality, but since a window's modality status isn't exposed to JS, there's no 
way I can think of to do this from JS (other than assuming you're modal and 
opening only modal windows).

Comment 9

[Dan M]

Attachment: force windows opened from a modal window to themselves be modal

Comment 10

[Dan M]

Hmmm. The above patch kind of works. It is indeed forcing windows opened from a 
modal one to themselves be modal, in the sense that code execution stops and an 
event queue is pushed, but for some reason it doesn't behave modally from a UI 
standpoint. That's a bit scary. One worries that this leaves open the possibility 
of closing a stack of modal windows out of order and all that implies. I don't 
have time to look into why this is right now.

Comment 11

[Dan M]

Attachment: better patch that fixes above complaints and actually compiles on linux

Comment 12

[David Hyatt]

a=hyatt

Comment 13

[Brendan Eich [:brendan]]

Please spruce up the IDL comments to be proper doc comments (/** ... */), and
don't add tabs (it looks like the + lines are indented with tabs).

Was CHROME_DEPENDENT not fully implemented before this patch?

/be

Comment 14

[Dan M]

Alright. I fixed the IDL comment style. I couldn't bring myself to claim every 
line of the tabbed IDL files, though. If you really want me to do that, I can do 
it in a separate checkin. And no, CHROME_DEPENDENT was already hooked up. I did 
allow content windows to be dependent/modal, though. That was for some reason not 
hooked up.