Cycling through windows has "invisible" window

VERIFIED FIXED in Future

Status

()

Core
XUL
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: Josh Aas, Assigned: Mike Pinkerton (not reading bugmail))

Tracking

({fixed-aviary1.0})

Trunk
Future
PowerPC
Mac OS X
fixed-aviary1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.
Assignee: asa → pinkerton
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets
Ever confirmed: true
(Assignee)

Comment 2

16 years ago
oh well.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Reporter)

Comment 3

16 years ago
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

15 years ago
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

15 years ago
> ..., 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

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

Comment 7

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

Updated

14 years ago
QA Contact: asa

Comment 8

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

Comment 9

14 years ago
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?
(Assignee)

Comment 10

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

Comment 11

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

Comment 12

13 years ago
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.

Updated

13 years ago
Flags: blocking-aviary1.0mac?

Comment 13

13 years ago
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).
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 14

13 years ago
Would this have not made it into 1.0 PR yet then?
Yes, Peter fixed this issue in bug 223545.
Status: RESOLVED → VERIFIED
Flags: blocking-aviary1.0mac?
Keywords: fixed-aviary1.0
You need to log in before you can comment on or make changes to this bug.