The firefox help window seems to be app modal. Can we make it window modal or not modal at all? I can't see why you'd want help to obscure anything more than the window you launched it from, if even that. Tested with avairy branch builds 2004071509

Asa, see bug 219865 for why this was WONTFIX'ed in Seamonkey Help. I once thought it'd be better to remove alwaysRaised as well, but in the end it did seem better. Now if the Browser contents are inaccessible when help is open, reopen this bug (but that isn't the case on this end).

I don't understand that logic. The overwhelming majority of novice users that this always raised state would help are also single browser window users. Let the help window be modal to the window that called it but not modal to other browser windows. That way power users who have several windows open can have help be modal to the one window where they needed it but not to the rest of the app.

Reopening. app-modal (or even window-modal) Help is an HIG violation for Apple/GNOME. Also, what's wrong with window-modal instead of app-modal? I'd rather see dependent instead of modal, but Windows is a different beast and nothing's set in stone.

(In reply to comment #3) > Reopening. > > app-modal (or even window-modal) Help is an HIG violation for Apple/GNOME. Its not really modal, just alwasy raised :). If I were to set it to modal, the browser contents wouldn't be accessible. > > Also, what's wrong with window-modal instead of app-modal? I'd rather see > dependent instead of modal, but Windows is a different beast and nothing's set > in stone. The problem is that if you set the dialog to modal, you can't access the original window. Currently, alwaysRaised makes the window always raised. I don't see the logic with having this only in the window that called it. There are some dialogs that pop up and Help needs to be displayed. Me personally, I'd have no idea how to do this (alwaysRaised to only the parent window). This might be a question for the XP Apps people.

I think that the whole "users losing their Help window" is a prety silly design consideration, but aside from that, name another major app that does this (don't cite Office 97, that's essentially eight year old software now). Given that bug 42557 is fixed, there's no reason to not add a control to turn this off. (Pref-driven, toggle via the Help toolbar, the pressed state will make it very clear it can be turned off) Also, always on top makes as much sense as this, maybe more. It might even behave better, since if you open Help, minimize it to access the browser, then alt tab to another app and back it'll tab back to a restored Help, not the window. Highly annoying "feature" and a big usability hit.

(In reply to comment #5) > I think that the whole "users losing their Help window" is a prety silly design > consideration, but aside from that, name another major app that does this (don't > cite Office 97, that's essentially eight year old software now). I know it sounds silly, but I would personally find it convient to follow directions without losing the Help Window. There was a study made on it that showed that users would prefer the Help Window to be above all other windows. Can't remember the bug they cited that in. > > Given that bug 42557 is fixed, there's no reason to not add a control to turn > this off. (Pref-driven, toggle via the Help toolbar, the pressed state will > make it very clear it can be turned off) Also, always on top makes as much > sense as this, maybe more. It might even behave better, since if you open Help, > minimize it to access the browser, then alt tab to another app and back it'll > tab back to a restored Help, not the window. Highly annoying "feature" and a > big usability hit. I was thinking about making a menu item to toggle the status (specifically a checkbox menu item). Neil has a patch for it and I'm trying to find it. The patch was never checked in because bug 225740 got in the way. I'll try and dig it up and hopefully check it into Seamonkey and Firefox.

Here's the patch Neil posted to bug 216426 but with a couple modificaations (other than just moving it to Firefox Help). Because alwaysRaised doesn't work on linux, I preprocessed the code out on that platform.

This bug's cluttering space in the list. Personally, I'm all for making the window completely un-modal, but I'm not familiar with any studies that have been done about it. I also don't feel comfortable reviewing this (and couldn't, anyways), so someone else with more knowledge needs to make a decision and take care of this.

It's indeed alwaysRaised: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/components/help/content/contextHelp.js&rev=1.2.2.1&mark=72#72

lets stick with what we have been shipping. -minus 1.0

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

I hate to bring up a Microsoft solution, but what about placing the help window to the right side of the current window like Microsoft does in most of its newer apps?

ok, this bug is starting to bug me. attached is a patch to remove alwaysRaised. Take your pick, do you want neil's patch or do you want to remove alwaysRaised? It makes no difference to me but we should checkin one of these patches because alwaysRaised is a bit of a pain for me in general, and I'd at least like some way to disable it.

Comment on attachment 153515 [details] [diff] [review] Neil's patch If this only works on Windows, then please to be replacing #ifndef XP_UNIX with #ifdef XP_WIN. Other than that, r=me. Sorry for the extended latency, I hope this still applies cleanly! ;) BeOS and OS/2 users will thank you! ;)

Comment on attachment 175004 [details] [diff] [review] removes alwaysRaised Sure sure, provoke me into reviewing the other patch... ;)

Fix checked in.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050312 Firefox/1.0+ The help window is still alwaysRaised...

Comment on attachment 153515 [details] [diff] [review] Neil's patch >+# alwaysRaised is not supported on an OS other than windows Wrong, alwaysRaised is well supported on mac.

Adds mac support. Sounds like making another preprocessor constant is the only way to get this done. Don't think there's an alternative way.

Comment on attachment 177284 [details] [diff] [review] Patch - adds alwaysRaised menuitem to mac I wish the preprocessor supported #ifdef XP_WIN || XP_MACOSX, but I'm not a Perl genious.

You could put it inside the makefile instead, something like this: +#ifdef XP_WIN +DEFINES += -DENABLE_ALWAYSRAISED_UI +#endif +#ifdef XP_MACOSX +DEFINES += -DENABLE_ALWAYSRAISED_UI +#endif

also, please update the comment in help.js ;)

Fix checked in.

(In reply to comment #22) > also, please update the comment in help.js ;) Gotta find a way to get rid of threads in Thunderbird :). Lost the comment in all the threads. Checked in the change.

v. Thanks!

Targetting bugs which were targetted to Firefox1.1 before the move to mozilla1.8beta2.