168692 - Cycling through windows has "invisible" window

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Josh Aas]

Using Mozilla 1.2Alpha on Mac OS X 10.2...

When using Apple-tilde (Apple-~) to cycle through windows, it always has an
"invisible window" in the cycle that really just looks like all other windows
being out of focus.

Recreate steps:
1. Open Mozilla
2. Open two browser windows (not tabs). Let them each load a page (Necessary?)
3. Apple-tilde through them and it will not just cycle between the two windows,
but a third "invisible" one.

Comment 1

[Henri Sivonen (:hsivonen)]

Confirmed. The hidden window participates in the window cycling even though it
no longer shows up on the system (Dock) window list.

Comment 2

[Mike Pinkerton (not reading bugmail)]

oh well.

Comment 3

[Josh Aas]

What exactly does "Oh well" mean? This seems like a pretty serious bug to me...
Its quite bothersome since I use the cycling keys all the time and I'm sure
others do to. Suppose I'll have to fix it myself. Can I have a tip as to where
in the Mozilla source this problem most likely resides?

Comment 4

[Brett Koonce]

Josh: (simplified)

Mozilla uses an invisible window as an old hack to keep everything working.  99%
of the time, it's nicely hiding: Apple's recent forcing of command-~ to switch
windows simply exposes an old piece of code.

Various attempts to kill this code have failed.  (See bug 71895)

Here's a proposal for a quick-n-dirty hack to fix this problem (which should be
marked trival, btw, hitting command-~ again is a fairly simple workaround): how
about some code that simply switches to window one when the invisible window is
brought to the foreground?

-Brett

Comment 5

[Ben Fowler]

> ..., btw, hitting command-~ again is a fairly simple workaround): how
>about some code that simply switches to window one when the invisible 
>window is brought to the foreground?

The unwanted behaviour is still in: When the invisible window is frontmost,
the menus change to Mozilla ones, but they aree not active. The UI is distorted
because single mouse clicks to not do what you expect and the visual 
appearance is all wrong. It would be nice if Apple could get involved
as the window in question has useful purpose in maintaining the programmer's
model of an application - that every window has a parent window. Perhaps 
this Adam and Eve of all Windows could be marked as Locked, that is not
selectable or actuve except during quitting ...

Comment 6

[Ignacy Niemczycki]

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

Comment 7

[Jo Hermans]

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

Comment 8

[Jo Hermans]

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

Comment 9

[Eric D.]

This bug is still present in Mozilla 1.6_, FireBird 0.8 and Netscrape 7.1 (all
latest versions as of 2004/1/20). Camino 0.7 DOES NOT suffer from this bug.

Perhaps it would be worth looking at Camino's code for inspiration on how to
deal with this bug since they have a common ancestor with FireBird and solved
the problem?

As an aside: this may have been a "trivial" bug over a year ago, but the fact
that it has persisted for that long suggests to me that it is need of a high
dosage pesticide application. Has it become an infestation?

Comment 10

[Mike Pinkerton (not reading bugmail)]

camino is a cocoa embedding app, not a xul app. nothing in the solution will
help you here. 

Comment 11

[Alex Eulenberg]

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

Comment 12

[posita]

I can verify that this is still present in 1.0 PR on OS X 10.3.5. It can be an
eyesore when using Apple's new Expose feature. Hit F10 or F11 and you'll see
this so-called "invisible" window in a not-so-invisible way.

Comment 13

[jag (Peter Annema)]

I believe this has been fixed. Last SeaMonkey Mac trunk build I tried (about two
weeks ago), the hidden window did not show up in the window cycle. I believe the
fix for not showing "hidden window" when using expose (bug 223545) also fixed
this bug (see bug 223545 comment 42).

Comment 14

[posita]

Would this have not made it into 1.0 PR yet then?

Comment 15

[Asaf Romano (gone)]

Yes, Peter fixed this issue in bug 223545.