309300 - Figure out always-on-top behaviour for Help cross-platform

Status: NEW

(SeaMonkey :: Help Viewer, defect)

Description

[Andre Sihera]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

When accessing help engine from the Help menu in the main window, or from
dialogs (e.g.
the Options dialog), a second top-level window is created, and appears selectable in
the taskbar. However, the parent browser window with all your tabs becomes
inaccessible,
thus making it impossible to use the help WHILE you're using the browser.


Reproducible: Always

Steps to Reproduce:
1. Open a web page
2. Select "Help Contents" from the "Help" Menu.

OR

1. Select "Options..." from the "Tools" Menu.
2. Press the "Help" button in the bottom right of the dialog.
Actual Results:  
Help window pops to front, task bar indicates a new top-level window, and
ALT+TAB shows a new top-level window icon. However, selecting the original
parent browser window is now impossible.

Expected Results:  
Browser window and help window should be independently selectable in the window
manager as they are top-level windows.

Comment 1

[Martijn Wargers (dead)]

Workforme with current trunk build, could you please retest with current trunk
or branch build?

Comment 2

[Andre Sihera]

Attachment: Trace file of Win32 GDI WM_... messages during Firefox execution

Added trace file.

Comment 3

[Andre Sihera]

I downloaded the latest trunk build from September 20th for Windows and tried
it. I still have the same problem with the Window stacking order. It is
reproducable in exactly the same way as specifed.

Please note that my system is [Windows 2000 Server, Version 5.00.2195, SP4]

I did some further controlled tests as follows (from empty screen):

1. Open the main firefox browser window.
2. Go to a web page
3. View the source of the page by selecting CTRL+U
4. Size the Source Viewer window and the Main Browser window so they are
   EXACTLY on top of each other.
5. ALT+TAB between the Browser window and the Source Viewer window. There
   should be no problem.
6. Go to the browser window and select "Help Contents" from the "Help" menu.
7. Size the Help Viewer window EXACTLY over the Browser window and the Source
   Viewer window.
8. ALT+TAB between the Browser window, the Source window, and the Help
   Viewer. On my Windows 2K system, the Help Window slips in and out of
   *focus* (it's window frame goes deselected, then returns to selected)
   however, the Help Window remains on top at all times rendering the other
   open windows inaccessible.

I used this control situation in a substantial investigation using external
inspection tools. I attach a trace file (MessageCapture.txt) to this report:

- Within the trace file, which is a capture of window events from the point
  of view of the BROWSER, I did two controlled situations where the Browser
  window was attempted to be brought to the foreground and then sent back to
  the background. Within the message stream for each test there are markers
  that allow you to see which group of messages relate to which action.

- In the case where the Help Window was Closed, some extra window messages
  were sent to the Browser window. These are highlighted with extra ">>>" at
  the beginning of the line.

You will notice that the only difference between the two traces is the lack
of PAINT-related events sent to the Browser window in the case where the Help
Window is open. I have programmed using Win32 SDK for many years and I know
that Windows only sends PAINT messages to windows where it has calculated
that there is painting to be done. If it has calculated, for some reason,
that no painting is to be done (e.g: window minimised, invisible, completely
behind a "topmost" window, etc.) then no PAINT messages are actually sent.
This is what is seen in the trace. WM_CANCEL_MODE is also a PAINT related
event and is only sent to a window that is calculated as being obscured by
some kind of system dialog. In the case where the Help Window is open, the
Browser Window is always obscured therefore no WM_CANCEL_MODE message is sent
when we switch between foreground and background.

I also wrote a program to query the GDI and return me all the attributes of
each open window in the Firefox application but, contrary to my initial
guess, the "WS_EX_TOPMOST" flag (used with CreateWindowEx) was not set.

Thus, I am seeing a situation where the Help Window is "always on top", and
Windows GDI knows it's always on top (hence the lack of PAINT messages being
sent to the Browser Window to redraw it and bring it to the front) and yet
there is no physical indication that the window has been created this way.

Maybe someone else who has a better idea of the source code can carry on with
the investigation from here.

Cheers.

Comment 4

[Martijn Wargers (dead)]

Wow! 
Well, I have no programming experience, but maybe you have the "Always on top"
option turned on? You can find it when you open the context menu in the help window.

Comment 5

[Andre Sihera]

Well, I'll be damned.

Indeed, that was the "problem". The "always on top" option on the Context Menu. 

Hmmm.

However, that said...

I'm one of these people who does RTFM before having a look around so there are
two questions I would like to ask instead:

1) Why is it that this is an UNDOCUMENTED feature? I spent a good time rummaging
the Help system by typing "always on top"/"on top"/"always on" an absolutely no
results came up for this feature.

2) This usage of context menu sure constitutes a UI breakdown. Context Menus are
designed to provide options that are normally available *through dialogs* but
within the context of the User's current action.

Why is it that the Help Viewer window with no menus, two buttons and a search
field has a Context Menu with a rack-load of undocumented options that are not
accessible from anywhere else?

I managed to use the help for many, many hours and it was not necessary to know
that there even was a context menu. Why should I have to? I see an empty window
with a search box and a button so why should I even assume that there is
anything to right-click?

A gross waste of my time, I have to say, but a perfect example of how a normal
user could get very frustrated making the same very, very easy assumption that
I made. Especially given that here is absolutey zero documentation on the
feature(s) either.

I'm off to file two more bugs...

Comment 6

[Martijn Wargers (dead)]

I'm sorry you had to discover it in this way.
I agree with you such a thing does not really belong in a context menu.
Could you post the bug numbers, of the two new bugs you file, here?

Comment 7

[Andre Sihera]

Bug #309740 has been filed to request review of Context Menu UI integration on all
platforms.

Comment 8

[Jesse Ruderman]

WTF?  I never would have guessed to look in that context menu for a way to
toggle Help's "Always on Top" behavior.  I always assumed that was just a bug too.

Comment 9

[Jesse Ruderman]

Also, it should default to not being on top, so you don't have to close it just
to try out the instructions it gives you.

Comment 10

[Andre Sihera]

Agreed...

Comment 11

[Martijn Wargers (dead)]

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

Comment 12

[Parkhideh]

I see Andre had beat me to this one :)
Now, why did I not find this bug report after searching for 20 minutes and then had to create my own duplicate (313302)?

1- Seriously, can we have a keyword in this bugzilla that is related to all things in the menu system (and if it is already there, please let me know).
2- I fully agree with Andre that Right Click is not a place for a system setting.  Or at least they should reflect back to some check box in the OPTION menu.

Thanks

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

A toggle button on the toolbar might be the best way to indicate this. The default should probably be switched as recommended until we're sure that all users all over the world have widescreen monitors :)

Comment 14

[Asaf Romano (gone)]

(In reply to comment #13)
> A toggle button on the toolbar might be the best way to indicate this.

CCing Kevin ;)

Comment 15

[Kevin Gerich]

Thanks Mano :) IE/Win has a help window that is on top by default. I assume this is why we do it. 

Do we really need a button on the toolbar that will rarely be used? AFAICT the standard place for the "Always on Top" menu item is the window context menu, accessed through the icon in the upper left corner or the taskbar on Windows. If we really, really need a toolbar item, it might be a good idea to create an Options dropdown menu button where we could put the Increase/Decrease text size commands as well as the Always On Top command.

Also, the On Top feature should be removed from Mac builds. We shouldn't force IE/Win's behavior on non-Windows builds. Separate bug?

Comment 16

[Mike Connor [:mconnor]]

The implementation of this was due to usability studies that showed the always on top behaviour helped ensure that people didn't lose the window, which may be worthless 3-4 years later, and quite possibly unnecessary for OS X which has an different enough window management system that users would understand this well enough.

Comment 17

[Mike Connor [:mconnor]]

Needs ui-review and possibly retesting of the usability factors.

Comment 18

[Parkhideh]

The whole issue started because the default of help window was "always on top".  Since I have not used IE, I wouldn't know; but other applications, including MS Visual Basic and netBeansIDE which have useful and often needed help treat the help as a spawned process and leave it to the user.
This idea of adding buttons etc. just complicates what has already been mentioned as "will be useless in a short time".  And I agree, Netscape's help has never done good.
So I suggest that leave the help to its own devices and do not manage it; under any OS.

Comment 19

[Mike Connor [:mconnor]]

Help Viewer will be dropped from Firefox in favour of a webapp,