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.

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

oh well.

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?

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

> ..., 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 ...

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

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

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

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?

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

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

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.

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

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

Yes, Peter fixed this issue in bug 223545.