Make Help window float in front of other windows.

VERIFIED FIXED in mozilla1.2beta

Status

SeaMonkey
Help Documentation
P2
normal
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: Sean Cotter, Assigned: Ian Oeschger (gone))

Tracking

Trunk
mozilla1.2beta
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Our recent usability test showed conclusively that the biggest obstacle to using
help is the fact that the Help window keeps disappearing. It would be much
better to let it float on top (in front of all other windows), so users could
keep it in view while they follow instructions.

Even if this can be done only when the window is opened from the Help window or
from nonmodal dialogs, it would be a huge improvement. 

Ideally it would also be good to be able to keep the Help window both nonmodal
and floating when opened from a modal dialog, as well.
(Reporter)

Comment 1

16 years ago
nominating for nsbeta1+, marking adt1
Keywords: nsbeta1
Priority: -- → P2
Whiteboard: [adt1]
Target Milestone: --- → mozilla1.0

Comment 2

16 years ago
Would be great! marking new
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

16 years ago
Sorry, this is on the "new feature" side of things, and it's late to add this
for beta. It's not a stop ship, which is what we should be considering at this
point for fixes to beta. Marking minus for now.

Let's try to get a handle on what it would take to implement. Because of the
great usability win, and on the assumption that
implementation is not too difficult and impact elsewhere is minimal (born out by
testing), we might be able to get this in for rtm. Once we understand the impact
better (awaiting answers to that in separate email thread), I'll mark
appropriately (with new milestone, etc.).

Comment 4

16 years ago
It sounds like Steve meant to nsbeta1- this.  Removing [adt1] to get it off the
radar.  If I misread the last comment and this ends up being a plus, please add
the impact back.
Whiteboard: [adt1]

Comment 5

16 years ago
So, has this missed the rtm boat, too?  It's probably easy to do on Windows. Let
me see if I can figure it out.
(Assignee)

Comment 6

16 years ago
Blake--any luck here? I haven't looked at it myself, but this is waxing in
importance as an improvement to the help system.

Comment 7

16 years ago
mpt was actively trying to wontfix a generic version of this bug. but this is a
reasonable justification for the feature.

Comment 8

16 years ago
You want to add "alwaysRaised" to the window.open flags in
extensions/help/resources/content/contextHelp.js. That is,

<window.open(MOZ_HELP_URI + "?" + encodedURI, "_blank",
<"chrome,menubar,toolbar,dialog=no,resizable,scrollbars");
--
>window.open(MOZ_HELP_URI + "?" + encodedURI, "_blank",
>"chrome,menubar,toolbar,dialog=no,resizable,scrollbars,alwaysRaised");
 
This works on Windows and Mac OS9 (and I believe on OSX as well (can't check
that right now, ugh, did I screw up my Mac build)) but unfortunately this isn't
implemented on Linux.

Comment 9

16 years ago
Marking nsbeta1+ for Buffy and re-setting milestone.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla1.0 → mozilla1.2beta

Comment 10

16 years ago
See also bug 161342 (help loads as modal window from Publish dialog [help] button). 

Updated

16 years ago
Blocks: 161765
(Assignee)

Comment 11

16 years ago
Created attachment 96315 [details] [diff] [review]
floating window patch

unfortunately, I only have a linux build with me here, but I will test this
further at home. thanks a lot, dan. will want to get this r/sr'd for check-in
ASAP.

Comment 12

16 years ago
Comment on attachment 96315 [details] [diff] [review]
floating window patch

I am kind of reviewing my own code but between the two of us there should be
warm bodies enough for an r=. Now the trick is implementing this on linux...
Attachment #96315 - Attachment description: modality patch → floating window patch
Attachment #96315 - Flags: review+
(Assignee)

Comment 13

16 years ago
ACCEPTING. But do we want this behavior all the time--like when you open the
Help window directly from the Help menu in the browser? There, the always on top
behavior seems a little annoying--and unexpected. 

Perhaps we could define two functions for getting help, and use this
always-on-top one only for context-sensitive help? Is that what we mean that we
want?
Status: NEW → ASSIGNED

Comment 14

16 years ago
I'm inclined to want to always have the Help window on top, no matter how you
got to it.
(Assignee)

Comment 15

16 years ago
Well, that's easier for me. The patch in this bug gets us that behavior. Just
need an sr now.

Comment 16

16 years ago
We definitely want Help window on top, always. 

Comment 17

16 years ago
Comment on attachment 96315 [details] [diff] [review]
floating window patch

sr=alecf
Attachment #96315 - Flags: superreview+
(Assignee)

Comment 18

16 years ago
Marking as FIXED (since it is fixed on windows/mac and there is no easy way to
do it on linux)
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 19

15 years ago
v
Status: RESOLVED → VERIFIED

Comment 20

15 years ago
Re Description:
> Our recent usability test showed conclusively that the biggest obstacle to 
> using help is the fact that the Help window keeps disappearing. It would be 
> much better to let it float on top (in front of all other windows), so 
> users could keep it in view while they follow instructions.

Right: *let* it float on top, but don't *make* it float on top--make it an
option, on by default, that users can turn off.

As for usability tests, don't test only with novice users!

Re:

> We definitely want Help window on top, always. 

No, not always--only when the user wants it that way.

Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.