87720 - Help broken when accessed from a modal dialog

Status: VERIFIED FIXED

(SeaMonkey :: Help Documentation, defect)

Description

[sairuh (rarely reading bugmail)]

seen using 2001.06.25.08-branch comm bits on mac. not a problem on winnt or
linux.

1. open Preferences dialog.
2. click the Help button, Help window appears.
3. try any of the following:
  * clicking any of the help links
  * resizing the Help window
  * closing the Help window by clicking the close widget.

result: nothing happens.

notes:
* the windowshade widget works, oddly.
* workaround: dismiss the Prefs dialog [i hit Cancel], and then the Help window
is accessible.

Comment 1

[sairuh (rarely reading bugmail)]

modality thing. of course. :)

Comment 2

[Ian Oeschger (gone)]

danm or saari: can you guys shed some light here? I am using (as I said I would 
in 46226) window.opener.open() from the preferences dialog to get as much 
non-modality as the preferences dialog would permit, but apparently mac needs 
something more. 

Can one of you suggest a way to open the help viewer from the modal preferences 
dialog that would properly give control to the help viewer? tanks

Comment 3

[Dan M]

  We just talked about this: the problem is, as Ian points out, the new window is 
given its opener's parent as its own parent. Or something like that. I'm not 
quite sure who wins here: the opening window or the calling window. I think it's 
the opening window. There was much nervous clearing of throats and we decided it 
might be possible to handle that more nicely, but it would be best to just open 
the Help window normally, and let the system sort it out.
  But now I realise that even that wouldn't work. I agree that the Help window 
doesn't want to be modal, but you're stuck with it because of the modal prefs 
window. You're kind of trying to defeat the Macintosh application-wide modality, 
giving it a more Windows- or Linux-like behaviour. We don't support that. On the 
Mac, a modal window shuts down the whole app. That's just standard Mac app 
behaviour. (On the up side, I'm told that Apple wants OSX apps to adopt the nicer 
window-specific modality most other OSes implement.)
  There's still a problem here; the duelling windows should be better behaved. 
But if you open the window in straightforward fashion and just let the system 
behave the way it wants to, it'll start behaving.

Comment 4

[Simon Fraser [no longer active]]

On 4.x, the Help window was a true floating window, for this very reason.

Comment 5

[Mike Pinkerton (not reading bugmail)]

and it was a hack from hell (i remember the code). please, let's not go back 
there.

Comment 6

[Simon Fraser [no longer active]]

There is no UI-sanctioned way on Mac OS to give the user access to content in a 
document window (like the help window) when a modal dialog is up. So, 
irrespective of our particular implementation restrictions, how *should* this 
work?

Comment 7

[Ian Oeschger (gone)]

On the other two platforms, is asking the browser to open the help window better 
than launching it straight from the preferences dialog? 

Because if this really is something that Mac prohibits (and if launching help 
from the browser really is better than the alternative, which conversations 
about this in 46226 and elsewhere led me to believe was the case), then we _can_ 
just take the Help button out of the mac's dialog overlays, and not permit 
context sensitive help on the mac. :(

Comment 8

[Dan M]

Ooo. Clarification on my above comment: the thing that wouldn't work was pipe 
dream #1a, not what we decided to go with. Merely opening the help window from 
the prefs window and doing nothing tricky (as we discussed and decided) should 
work fine on all platforms. It's just that you'll get a modal window for Help 
whether or not you want that, because you're opening it from a modal window 
(well, except on Linux, where the Prefs Window isn't modal by default. Man, this 
is over-complicated.)

(Simon: since we're spinning our own modality, we could consider blowing off the 
UI guidelines and making windows window modal, like modal Windows windows. What a 
lovely sentence that was.) But barring that, it is of course pointless even to 
try to make the Help window nonmodal, since the modal prefs window already has 
the whole app's attention and will be adamant about keeping it.

And yes, on Linux and Windows -- I haven't tried this you understand -- but 
picturing how the code works in my head, I think opening the Help window from the 
browser would probably work fine, even if the browser is already hosting the 
modal Prefs Window. Maybe not. There is a possible snag with stalled NSPR event 
queues. But if everything is well behaved, it should work. (I should mention that 
the Help window is largely empty on my Windows and Linux builds today; I wonder 
if that's more fallout from the funny parenting.) I wouldn't advocate utterly 
removing the button from Mac builds, though.

Comment 9

[Ian Oeschger (gone)]

Attachment: reverting to pref dialog launch of help viewer for mac's sake

Comment 10

[Ian Oeschger (gone)]

danm, smfr, and/or saari: can you guys review this last patch? I guess we are
going to have to go with window.open on the prefs dialog and put up with having
the help viewer coerced into modality to the preferences dialog (b/c, if I
understand danm correctly, when a modal window launches a non-modal, that latter
is forced to become modal).

Comment 11

[Dan M]

  Yes: if you don't ask for modality, the window will be unmodal if possible; 
otherwise it'll be forced modal anyway. So it should always work, not explicitly 
specifying modality.
  Patch looks good to me. r=danm.

Comment 12

[Simon Fraser [no longer active]]

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

Comment 13

[Ian Oeschger (gone)]

cc'ing blake for review

Resolving this modality problem looks like it's going to be fairly important. I 
wish there was some other way than to revert to modality to the prefs dialog on 
all plats, but this seems to be the concensus, at least for now.

Blake, would you mind sr=ing this patch (40302)? It's just going back to 
window.open from window.opener.open for context-sensitive help. Thanks a lot.

Comment 14

[Blake Ross]

sr=blake

Comment 15

[rudman]

We need this in. Check in on the trunk first, and we'll confirm that it works
there (Terri, can you test this please).

Adding nsBranch keyword.

Comment 16

[Ian Oeschger (gone)]

Just checked in fix for modality on trunk. Terri, let me know how it looks 
(particularly on the mac), and we'll see about getting this on the branch 
tomorrow. Thanks

Comment 17

[Dan M]

Note that Ben just seems to have successfully argued for a nonmodal preferences 
window. If allowed to actually land that change, the above patch is still correct 
and all these problems are simply no longer.

Comment 18

[Ian Oeschger (gone)]

Marking FIXED: modality is still less than ideal, but problem described here 
about the mac is resolved with check-in to the trunk yesterday, check-in to the 
branch just now.

Comment 19

[Terri Preston]

Verified mac 9.1 build 2001081308