195888 - Problems when dialogs launch help

Status: VERIFIED FIXED

(SeaMonkey :: Help Documentation, defect)

Description

[[e-mail]]

Steps to reproduce problem:
1. Open Editor
2. Open a dialog, such as Insert Link
3. Click Help

Expected results: Can switch back to dialog while help is open

Actual results: Dialog is inaccessible/unresponsive while help is open

On Linux you can raise the dialog above help but it is still unresponsive.

Comment 1

[[e-mail]]

Attachment: Proposed patch

An additional benefit is that passing the parameters as a parameter block
instead of encoded in the URI allows the code to be simplified.

Comment 2

[Ian Oeschger (gone)]

Comment on attachment 116192 [details] [diff] [review]
Proposed patch

nice looking, neil. thanks. r=oeschger

Comment 3

[Paul Wyskoczka]

Update QA contact

Comment 4

[Alec Flett]

Comment on attachment 116192 [details] [diff] [review]
Proposed patch

ugh, why go through nsIDialogParamBlock when you're just going from JS=>JS ? 

Instead, just pass them as arguments to window.open and let the consumer use
window.arguments[0], and window.arguments[1]

Comment 5

[[e-mail]]

Comment on attachment 116192 [details] [diff] [review]
Proposed patch

I can't open a window from a dialog (any window opened from modal window is
automatically modal) so I need to use the WindowWatcher interface. This only
takes a single parameter which has to be an nsISupports or an nsISupportsArray
neither of which is directly suitable for passing strings.

Comment 6

[Dan M]

Bug 161342 (which this bug is a duplicate of, by the way) explains why the help
window is modal. Follow its links to other bugs for a reading extravaganza.

That said the patch in this bug is probably a fine fix. We should have thought
of that. It avoids the 161342 modality problem by severing all contact between
the help window and the dialog which launched it. It also bypasses a bunch of
wrapper code in window.open but at time of writing this shouldn't hurt anything.
Calling WindowWatcher directly is acceptable and should remain so.

Two things: please add a comment; something like what I just said. You're using
a backdoor and it should be noted in the code. Also consider adding alwaysRaised
to the help window featureset:

+ ww.openWindow(null, MOZ_HELP_URI, "_blank", "chrome,all,dialog=no", params);

+ ww.openWindow(null, MOZ_HELP_URI, "_blank",
+               "chrome,all,alwaysRaised,dialog=no", params);

(see bug 136647).

Comment 7

[[e-mail]]

Ah, so could this break bug 87720?

Comment 8

[Dan M]

well... I encourage you to try it first. But no, I'd be surprised if this
affected 87720, which was a correction for a previous attempt to solve this same
problem in a very different way.

Comment 9

[Alec Flett]

Comment on attachment 116192 [details] [diff] [review]
Proposed patch

Ugh, more nsIDialogParamBlock! one of these days I've got to fix bug 194289

sr=alecf

Comment 10

[Asa Dotzler [:asa]]

Comment on attachment 116192 [details] [diff] [review]
Proposed patch

please land first thing in beta. thanks.

Comment 11

[[e-mail]]

Fix checked in.

Comment 12

[sairuh (rarely reading bugmail)]

this now works for win2k and linux (rh8.0), but this is still a problem on OS X.
is that expected, on mac, since mac uses sheets for such dialogs?

Comment 13

[Dan M]

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

Comment 14

[Dan M]

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

Comment 15

[Daniel Wang]

v