99284 - Help window is modal

Status: VERIFIED DUPLICATE of bug 195888

(SeaMonkey :: Help Documentation, defect)

Description

[Ken Harris]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010907
BuildID:    2001090705

The help window is modal, i.e., I can't do other things when
it's visible.  For example, if I'm looking at Image Properties
in Composer and click Help, I'm unable to edit the properties
as long as Help is on the screen.

Reproducible: Always
Steps to Reproduce:
1. Go to any site (like www.mozilla.org)
2. Press ctrl-E to edit the page
3. Double-click on the lizard image
4. In the properties window, click "Help"

Actual Results:  As long as the Help window is visible, no properties can be
changed.

Expected Results:  Let me change properties while reading help!

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[James Green]

According to Fabian, it's modal because windows inherit the modal state of their
parent, and this dialog this modal to the help is also. Apparently this is a
hack to stop other problems and danm knows what's going on... Reassigning to him.

Comment 3

[Dan M]

Of course the current Mozilla Linux build has modality problems anyway because
we're using gtk's implementation of modality. Even were the "hack" removed so
that the help window was no longer modal, gtk would still suppress interaction
with all but the modal properties dialog from step 3 above. (Though that's
slated to be fixed: see bug 65521.)

Sigh. I forget why we had to make children of modal windows modal themselves. I
know it's a big problem on Mac OS 9 (bug 87720). You'll certainly be exercising
some of the underlying toolkit in ways that it doesn't want to be stretched if,
say, you open a stack of interspersed modal and nonmodal windows and start
closing them in the middle.

I know that allowing modal windows to parent nonmodal ones has caused us much
pain in the past. I think many subsystems assume a kind of lifetime model that
can't be guaranteed without propagating the modality down through all child
windows of a modal one. It could well mostly work save some horrible deadly edge
case or ten. I'm not prepared to be Pandora to this box, even if it does smell
like candy inside. The potential win isn't worth the potential pain. Closing.

Comment 4

[John Levon]

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

Comment 5

[Dan M]

Additional notes-'n-knowledge: the question in comment 3 above ("Sigh. I forget
why...") is probably answered by bug 15574; see especially bug 15574 comment 4.
 Also bug 19221 and bug 56677. It may be worth revisiting the issue, though,
because the modal help window is collecting a slow but steady stream of
complaints (bug 99284, bug 161342) and because the restriction may no longer be
necessary since a rewrite of the modality event system was snuck in (bug 65521,
bug 126786).

Comment 6

[Frank Wein [:mcsmurf]]

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

Comment 7

[Brant Gurganus]

v

Comment 8

[R.K.Aa.]

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

Comment 9

[R.K.Aa.]

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

Comment 10

[R.K.Aa.]

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

Comment 11

[Daniel Wang]

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

Comment 12

[Daniel B.]

See comments in bug 204761.

Comment 13

[Daniel B.]

> I know that allowing modal windows to parent nonmodal ones has caused us much
> pain in the past. 

If that implementation aspect is still relevant, can the open-help action
in a model window create a new window whose parent is the previous non-modal
window?

Comment 14

[Daniel Wang]

add this to your bookmark to open Help window as non-modal:

javascript:params=Components.classes["@mozilla.org/embedcomp/dialogparam;1"].createInstance(Components.interfaces.nsIDialogParamBlock);params.SetNumberStrings(2);params.SetString(0,"chrome://help/locale/mozillahelp.rdf");params.SetString(1,"welcome");ww=Components.classes["@mozilla.org/embedcomp/window-watcher;1"].getService(Components.interfaces.nsIWindowWatcher);ww.openWindow(null,"chrome://help/content/help.xul","_blank","chrome,all,alwaysRaised,dialog=no",params);

Comment 15

[Dan M]

Daniel (comment 13): it's been tried. bug 87720. However this bug has been
fixed: the help window is no longer modal. See bug 195888 (from which the script
in comment 14 was taken). If you know of an exception (the case spelled out in
this bug is not one) make a new bug and assign it to neil or oeschger of bug
195888 fame.

Comment 16

[Daniel B.]

Comment #15 >

> ... this bug has been fixed: the help window is no longer modal. 

Oh, okay.  Cool.  

The WONTFIX resolution confused me.  (Can it be changed to something more
intuitive?)

Comment 17

[Dan M]

i s'pose

Comment 18

[Dan M]

fixed by bug 195888

*** This bug has been marked as a duplicate of 195888 ***

Comment 19

[Daniel Wang]

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

Comment 20

[R.J. Keller]

VERIFIED