Firefox Help window should not be alwaysRaised

VERIFIED FIXED in mozilla1.8beta2

Status

SeaMonkey
Help Viewer
VERIFIED FIXED
13 years ago
a year ago

People

(Reporter: asa, Assigned: R.J. Keller)

Tracking

unspecified
mozilla1.8beta2

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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
(Assignee)

Comment 1

13 years ago
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).
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

13 years ago
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 4

13 years ago
(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.
(Assignee)

Comment 6

13 years ago
(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.
(Assignee)

Comment 7

13 years ago
Created attachment 153515 [details] [diff] [review]
Neil's patch

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.
(Assignee)

Updated

13 years ago
Attachment #153515 - Flags: review?(bugs)
(Assignee)

Updated

13 years ago
Attachment #153515 - Flags: review?(bugs) → review?(mconnor)
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.
Assignee: rlk → jwalden+fxhelp
Status: REOPENED → NEW
Flags: blocking-aviary1.0?

Comment 9

13 years ago
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
Summary: Firefox Help window should not be modal → Firefox Help window should not be alwaysRaised

Comment 10

13 years ago
lets stick with what we have been shipping. -minus 1.0
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Target Milestone: --- → After Firefox 1.0

Comment 11

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

Comment 12

13 years ago
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?
(Assignee)

Comment 13

12 years ago
Created attachment 175004 [details] [diff] [review]
removes alwaysRaised

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.
Assignee: jwalden+fxhelp → rj.keller
Status: NEW → ASSIGNED
Attachment #175004 - Flags: review?(mconnor)
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! ;)
Attachment #153515 - Flags: review?(mconnor) → review+
Comment on attachment 175004 [details] [diff] [review]
removes alwaysRaised

Sure sure, provoke me into reviewing the other patch... ;)
Attachment #175004 - Attachment is obsolete: true
Attachment #175004 - Flags: review?(mconnor)
(Assignee)

Comment 16

12 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago12 years ago
Resolution: --- → FIXED
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...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
(Assignee)

Comment 19

12 years ago
Created attachment 177284 [details] [diff] [review]
Patch - adds alwaysRaised menuitem to 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.
Attachment #177284 - Flags: review?(mconnor)
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.
Attachment #177284 - Flags: review?(mconnor) → review+
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 ;)
(Assignee)

Comment 23

12 years ago
Fix checked in.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 24

12 years ago
(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!
Status: RESOLVED → VERIFIED
OS: Windows XP → All
Hardware: PC → All
Target Milestone: Future → Firefox1.1
Version: 1.0 Branch → Trunk
(Reporter)

Updated

12 years ago
Component: Help Viewer → Help Viewer
Flags: review+
Flags: blocking-aviary1.0-
Product: Firefox → Toolkit
Target Milestone: Firefox1.1 → ---
Version: Trunk → unspecified

Comment 26

12 years ago
Targetting bugs which were targetted to Firefox1.1 before the move to
mozilla1.8beta2.
Target Milestone: --- → mozilla1.8beta2
Blocks: 295904
Product: Toolkit → Seamonkey
You need to log in before you can comment on or make changes to this bug.