204761 - windows (esp. help) raise to top incorrectly when activated

Status: VERIFIED DUPLICATE of bug 216426

(SeaMonkey :: Help Documentation, defect)

Description

[Daniel B.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

The help window (from the Help menu's Help Content menu item) won't let other
Mozilla windows be raised above it.  If that behavior is optional, then it's
a (UI design) bug that the help window itself doesn't have a control to turn
off the option.


Reproducible: Always

Steps to Reproduce:
1.  Start in a Mozilla browser window.
2.  Activate the Help Content menu item.
3.  Try to raise the browser window above the help window.
4.  Open a new browser window and try to raise it above the help window.
5.  Open some other Mozilla window (e.g., the Bookmark Manager window), and
    try to raise it above the help window.

Actual Results:  
The help window remained on top, obscuring the windows that the user requested
to see.

(Additionally, the help window had no menu item (or button, etc.) for turning
of the always-on-top behavior.)

Expected Results:  
Mozilla should not have prevented the user from raising another window to be in
front of the help window.

Two acceptable behaviors are:
- don't set the help window to "always-on-top" mode in the first place
- make the behavior optional _and_ make it easy to see (in the help window
  itself) that the behavior is optional, ideally with a UI control to toggle
  the setting

Comment 1

[Daniel B.]

Oh, geez, here's some really weird raising/lowering behavior.  This may be an 
interaction between MS Windows and Mozilla.

From a browser window:

1. Open the help window (Help Contents action).

   The help window appears and is on top of the browser window.  (Consistent
   so far.)

2. Click on the mail icon at the bottom of the browser window.

   The mail window appears, is on top of (in front of) the browser window, 
   and is below (behind) the help window.  (Still consistent.)

3. Close the mail window.

   The browser window is on top of the help window.  (Weird.  You can't get 
   that condition when you want it.)

4. Click on the mail icon again.

   The mail window re-appears, and is below the browser window (that is, the
   requested window is below the window in which the request was made), and
   and is below the help window.

5. Click on the mail icon a third time (without closing the mail window). 

   The mail window is in front of both the browser and help windows.

6. Click on the mail icon a fourth time.

   The mail window is in front of the browser window and behind the help window.

I also saw other weird behavior I can't report precisely.  I think I saw the
Help window selected (indicated by MS Window's titlebar coloring) when it
wasn't on top (when it was partially obscured by another window), and when I
tried to raise it, nothing happened.

(Note that steps three and four above suggest that the browser window is 
being set to "keep on top" mode or being raise to a "keep on top" layer.)

Comment 2

[Daniel B.]

I wrote:

> ... suggest that the browser window is being ... raise[d] to a "keep on top" 
> layer.)

I take that back.

After a bunch of opening, closing, raising, and lowering to write my previous 
comment, now NONE of my Mozilla windows can be raised above any of my other 
windows (NTEmacs, Windows Explorer, Windows Task Manager).

Is this just a little programming bug with really screwy symptoms, or a major
lack of analysis and design?

Comment 3

[Daniel Wang]

*** This bug has been marked as a duplicate of 99284 ***

Comment 4

[Daniel B.]

> This bug has been marked as a duplicate of 99284.

This report isn't a complaint that the help window is modal.

(The other windows work when the help window is open, so it certainly
isn't modal in any usual sense (of blocking parent windows).)

This report is about really screwy window-raising and -lowering behavior.

(Re-opening for re-evaluation.)

Comment 5

[Daniel Wang]

this bug is a dupe of either bug 194532 or bug 193348 (both of
which are dupes of bug 99284)

Comment 6

[Daniel B.]

> this bug is a dupe of either bug 194532 or bug 193348 (both of
> which are dupes of bug 99284)

How?

* Bug 193348 and bug 194532 are reports that Help is on top.

  This one is a report of screwy implementation behavior.  (If Help is currently
  supposed to stay on top, it doesn't do so consistently.)

* Bug 99284 is a report that Help is modal.

  This one is NOT about it being modal.  

Yes, this report is related to those, but it's different.

Comment 7

[Hermann Schwab]

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

Comment 8

[Daniel B.]

1.5a update:  This bug still exists in build 2003071814.

Comment 9

[Gabriele Fava]

Apart the weird behaviour of comment #1, I heard there are different views
whether help window should be always on top or not; personally I think that is
very comfortable in some situations and bothering in other. So I think there
should be a toolbar button or menu selection to turn off/on the always on top
thing, maintaining as default the always on top. I don't think it should be
handled from the preferences panel, because as I already said it is good
sometimes and bad other, for the same person.
The always on top correct behaviour should be always on top of other mozilla
windows, but it'd be very good if it maintains the normal positioning with the
other windos, as it's now more or less.

Comment 10

[Gabriele Fava]

shouldn't this be set as "new"?

Comment 11

[Daniel Wang]

*** This bug has been marked as a duplicate of 99284 ***

Comment 12

[Gabriele Fava]

I can't believe, I was just writing a two pages comment to point out why this is
wrong...
haven't you saw my postings on bugs 194532 and 193348?

Comment 13

[Gabriele Fava]

AS THIS (comment 1 - and 0, by the way), THIS STILL TAKES PLACE, while 99284 is
risolved > duplicated of 195888 > fixed

Comment 14

[Gabriele Fava]

well nope it doesn't...
sick... seemed so...
well I'm sorry for the mess made, this bug (maybe after changing the title
-something like If Help is currently supposed to stay on top, it doesn't do so
consistently-) is possibly really a duplicate.

Comment 15

[Dan M]

The help window is supposed to stay on top: see bug 136647. A quick search of
bugzilla turns up two other bugs complaining about that behaviour since it was
implemented. Sigh. It was intentional, and not everything deserves to be a
preference. Personally I just keep the darn thing closed.

That said, the funky stuff going on in comment 1 would be a bug. However it
doesn't happen on my system, also Windows XP. This sounds rather like that
long-recognized Windows-specific problem with an incorrect window being
activated as other windows are closed. I consider it a bug in the OS. See bug
22658, especially bug 22658 comment 32. That's supposed to be fixed, though the
fix has been tweeked on occasion. See most recently bug 189085.

I notice the last piece of that last bug was checked in on April 1st 2003, which
also happens to be the date of the Mozilla build the bug reporter is using. (So
that would be the last build ever made that didn't include that checkin.) I'm
curious; does the problem still happen to you with a more recent build?

If not, yay. If yes, I'm stumped. As I said I can't reproduce it.

Comment 16

[Timwi]

Regardless if it's intentional or not, leaving the help window always on top
without giving the user any control over it is stupid. This is the first problem
I encountered when first trying Mozilla, and so far it's stayed in my memory as
the most annoying. I was trying to learn about the keyboard shortcuts, so I
thought I'd have the help window open while trying them, but that wasn't possible.

Seeing as the original description (Comment #0) describes a problem that still
exists and has not been fixed, and as Bug 99284 is talking about a different
problem (thus this is not a duplicate), I vote for reopening this bug.

Comment 17

[[e-mail]]

I didn't spot the on/off request so I confirmed bug 216426 instead...

Comment 18

[Gabriele Fava]

The bug in comment 1 does not occur to me, so I thought that perhaps that was
really dependant on bug 99284, now resolved; I thought that if Daniel (Wang-
there're dozens of Daniel working on these help bugs!) marked this as duplicate,
perhaps he knew what he was doing, so I trusted him noticing that comment 1 does
not take place any more. I didn't tried comment 1 before fixing of bug 99284,
and I'm not a programmer so I couldn't say anything more on the question

Right now, do you read what I wrote after a night spent on these bugs? I said:
this bug din't eventually regarded what was wrote in the title: it dealt with
bug in comment 1. So, let who can change the title change it to something like
"If Help is currently supposed to stay on top, it doesn't do so
consistently", so that its marking as duplicate makes more sense; then, if
you're still not sure that it doesn't take place right now because of bug 99284
fixing, just mark it as invalid.

All that just to make clearness, for it took me hours to understand the web of
bugs regarding help window issues and if you want people to cooperate on bug
solving there should be take care on each single bug, without trying to mark all
the world duplicate of x (by the way, bug 99284 has been a duplicate of 195888
for more than 3 months).

Comment 19

[Dan M]

I have to agree with Daniel B, Gabriele and Timwi, the latter of whom is clearly
the best and smartest of us all, that this bug isn't a duplicate of bug 99284.
Comment 0 is a duplicate, but this bug was quickly morphed into something new.
For future reference, it's better to open a new bug than morph an old one. The
misunderstanding happening in this bug is the reason why.

The problem described in comment 1 and 2 could be related to the Help window's
layering (it tries to stay on top) but would seem to have nothing to do with its
modality or owned state, since it's no longer modal or dependent (it's opened
with features "chrome,all,alwaysRaised,dialog=no" in contextHelp.js). Against my
own advice, I'm changing the subject as Gabriele suggested and reopening.

That said, I repeat the juicy parts of comment 15. I cannot reproduce any part
of this bug on my Windows XP system. I cannot do it here or there, I cannot do
it anywhere. I cannot see it in a box. I cannot see it with a fox. Nope, can't
reproduce the bug. On the strength of my own experience I'd close this bug
"worksforme." That's how much I can't reproduce this bug.

I would feel better if the people who can see the problem would assure me that
they're using a build of Mozilla newer than 20030401. Any date more recent.
Something from today would be really keen. But even 20030402 would be helpful.
And I'd feel better if you'd reboot your machine before trying again, because
with no help from Mozilla my XP box occasionally achieves a weird state where
window activation is flaky, all on its own. It gets better when I reboot.

If none of that helps, are you certain there aren't some other steps required
after launching Mozilla before step 1? Because, have I mentioned I can't
reproduce this bug? And I'm more likely the guy who'll fix it than the current
assignee? But I'm useless if I can't reproduce it?

Comment 20

[R.J. Keller]

--> me

Reporter, are you saying that alwaysRaised is inconsistent in ONLY help (from
what it looks like in comment #4) or in all dialogs that are alwaysRaised (from
what it looks like in the summary)? If it's in all dialogs, then this needs to
be moved to a different component and reassigned.

Comment 21

[Daniel B.]

> Reporter, are you saying that alwaysRaised is inconsistent in ONLY help (from
> what it looks like in comment #4) or in all dialogs that are alwaysRaised
> (from what it looks like in the summary)? ...

If you want to know what I was reporting, ignore the summary.  Someone 
changed it. 

Comment 22

[Dan M]

Daniel: you reported at least two things in this bug. The issue in comment 0 has
been moved to bug 216426, where it'll have a happy life. One bug, one bug
report, one line of discussion, one fix. Hopefully. That leaves this sad little
fellow to cover the separate issue raised in comment 1, which is how the summary
now reads.

Wow. Deaf ears, I'm getting. This bug fell out of control and became confusing.
Even to the reporter. No kidding. Next time you have two bugs to report, you
know what to do. Daniel, if the comment 1 issue is no longer a problem, this bug
could happily be closed. If it is still a problem, there are a couple of minimal
things it needs for verification, as pointed out repeatedly above.

Comment 23

[Daniel B.]

> if the comment 1 issue is no longer a problem, this bug could happily be 
> closed. If it is still a problem...

Yes, it is still a problem in version "Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.5a) Gecko/20030718"

> ...are you certain there aren't some other steps required after launching 
> Mozilla before step 1? 

No, I'm not.  I'll try to check again next time I can re-start Mozilla.

Daniel

Comment 24

[R.J. Keller]

Does comment #1 only happen with help? What other dialogs are alwaysRaised?

Comment 25

[[e-mail]]

Only Help (which is a window, not a dialog) is alwaysRaised.

And I see the problem too, especially the bit about raising over other tasks.

Comment 26

[Daniel B.]

I wrote:

> I'll try to check again next time I can re-start Mozilla.

Okay, here's what I'm seeing:

- Start Mozilla.
- Select menu item Help Contents.
- Help window appears (raised).
- In browser window, click on e-mail icon at bottom.
- E-mail window appears, behind help window.
- Click on e-mail window.
- E-mail window rises to front.
- Click on help window.
- Help window fails to won't rise above e-mail window.

A little later (sorry, I didn't track exact steps), clicking on the e-mail
window won't raise it above windows of other applications.  Even double-
clicking on title bar, which does maximize the window, leaves it behind
other-application windows.  When the help window is closed, then the
e-mail window can be raised over other applications' windows.

Daniel

 

Comment 27

[Dan M]

This bothers me. The window layering code is mine and I'd like it to work. I'll
want to review any patch to fix it but I won't be able to come up with one
because it all works fine for me (Windows XP SP1).

- Start Mozilla.
- Select menu item Help Contents.
- Help window appears (raised).
- In browser window, click on e-mail icon at bottom.
- E-mail window appears, behind help window.
- Click on e-mail window.

email window stays underneath help, as it should. Now, it *activates*. It gets
keyboard and mouse focus and if I hit Alt-F4 at this point it's the mail window
that closes, despite its being beneath the help window. I just tried this with
an optimized build of the 1.4 branch and a debug build of the trunk, both made
two days ago.

You guys don't have any system modifications, do you? Unusual registry settings?
Tweak UI?

Comment 28

[Daniel B.]

> You guys don't have any system modifications, do you?

Not much, and nothing I'd expected to cause window-handling
problems.  

I have changed Windows Explorer and GUI settings such as:

- change from Windows XP cartoon look to traditional Windows look
- show full path in address bar
- show full path in title bar
- don't hide hidden files, protected files, system folder contents
- don't hide extensions
- no "personalized menus"
- most XP effects turned off (e.g., sliding buttons, combo boxes;
  fading menus in/out)


> Unusual registry settings?  

Only putting the Control key back where it belongs.

> Tweak UI?

No.

Comment 29

[R.J. Keller]

Well, on this end, alwaysRaised doesn't work at all on Mandrake Linux 9.1 with
Moz 1.5b nightly, but I can't reproduce this at all on Windows XP SP 1.

Comment 30

[[e-mail]]

I find it easier to demonstrate the problem if you have another app open.

1. Open Mozilla browser
2. Open Mozilla help
3. Open another app
4. Try to raise Mozilla browser

Actual results: browser activates, but doesn't raise above other app

Expected results: browser raises above other app, but not above help

Comment 31

[Dan M]

R.J. (comment 29): Window layering was never implemented on Linux. I suspect it
can't be done without amateurish, bouncing windows or tying yourself to a
specific window manager. We'd love to have an implementation.

neil (comment 30): Now that part of the bug I can reproduce. Heh. That's never
worked at all. That's embarrassing. You know I was wrong about this being two
bugs. There are in fact three bugs here. comment 0, comment 1 and comment 2/30.
This time I am following my own advice, splitting that third part off into
separate bug 217012.

That bug has a patch. I don't see how it could affect the comment 1 part of this
bug but I suppose it's worth trying. If it does affect comment 1 (again I don't
see how it could) then I'd still argue their different steps to reproduce and
slightly different effect makes them separate, though related, bugs.

Comment 32

[mhonline]

<quote>
- E-mail window appears, behind help window.
- Click on e-mail window.
email window stays underneath help, as it should
<unquote>

well Dan, what can we you to make you understand, where the problem is ?
take it sportive: it is an unforced error, it just happend
.
An "always on top" window might be a good idea in a teaching-mode (user
controlled !), but nowhere else. 
It must be terminated, as it is a wrong idea about how windows/tasks should be
handled.

rgds
Martin 

Comment 33

[Dan M]

mhonline: All Mozilla UI decisions make someone unhappy. Every single one.
alwaysRaised Help has collected very little hatemail in the year since it was
implemented, so I consider it a relatively uncontended success. But we're
talking about another bug, bug 216426. *This* bug has become the "it'd be nice
if alwaysRaised actually worked when you wanted it to" bug.

Comment 34

[Daniel B.]

> ...All Mozilla UI decisions make someone unhappy.  Every single one.

Then somebody isn't considering all the options.  


For example, if the question is "how should the help window work regarding
being on top or not?" then the options are not just:
1.  always on top
2.  like a regular window.

There is also:
3.  has an "Always On Top" menu item like MS Window's task manager--
    the user can easily select the behavior.

Comment 35

[Daniel Wang]

severity -> major. This breaks certain UI functionality (from user point of
view). + helpwanted to keywords.

Comment 36

[R.J. Keller]

Daniel, can you see if this happens only in help? Not sure if there's other
alwaysRaised dialogs, but I have a feeling that this is an XP Apps bug.

Comment 37

[Dan M]

1) Daniel B. (comment 34): 
>> ...All Mozilla UI decisions make someone unhappy.  Every single one.
>Then somebody isn't considering all the options.  

Heh. Heh heh heh. No disrespect intended ... I mean, you seem like a good guy
... but that's funny. I look forward to hearing from you after you've been in a
few good UI fights. See bug 219865 comment 7 for my own analysis of this
decision. Which, if I do say so, and I do, is worth reading.

2) R.J. (comment 35): Help is the only alwaysRaised window in the whole product.
There are no alwaysLowered windows. It's possible to make an alwaysRaised window
from signed content script, but I think it's safe to say no one ever has. That's
one of the reasons I like the alwaysRaised Help window. It's the only exposure
most people have to testing the z-level windowing code.

3) As I've mentioned I can't reproduce this bug. Thank Lucky Charms someone else
owns it. The part I can reproduce, outlined in comment 30, has been fixed (that
was bug 217012) on the trunk in builds 20030925 and later. Has that fix had any
effect on the problems outlined in comments 1 and 2?

Comment 38

[Dan M]

No takers on Daniel's "does this still bug you?" challenge? I can make it
perhaps more interesting. Four days ago I checked in a serious whipping on the
window layering code. Since I (still) can't reproduce the problems in comment 1
and comment 2, I checked in no code specifically to address those issues but
maybe, just maybe, I accidentally fixed them while delivering the general
layering punishment?

If you are running a build made 20031007 or later and install the UI extension
(see bug 42557), you'll be able to alter a window's layer after it has been
opened. I'm curious whether that could be used to shine any more insight on the
problem.

Comment 39

[Dan M]

See also similar bug 222042, which I thought for a moment might be the same thing.

Comment 40

[R.J. Keller]

Dupe of 216426. I would mark this WONTFIX, but the report mentions that a UI
should be added if we want alwaysRaised in help, which is done in bug 216426.

*** This bug has been marked as a duplicate of 216426 ***

Comment 41

[Robin Monks]

VERIFIED