Closed Bug 223545 Opened 21 years ago Closed 20 years ago

Mac OS X 10.3's expose feature reveals "hidden" window

Categories

(SeaMonkey :: General, defect)

PowerPC
macOS
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: peterv)

References

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: [fixed on trunk])

Attachments

(3 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007

Version 10.3 of Mac OS X (aka "Panther") contains a feature called "expose" that
shrinks and tiles all windows, allowing the user to choose another window to
bring to the foreground.  When using this feature with Mozilla, an extra window
labelled "hidden" is revealed.  Clicking this window to bring it to the
foreground does nothing, though.

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla
2. Press F10 to tile all application windows


Actual Results:  
The additional "hidden" window is shown.

Expected Results:  
Only the user-visible mozilla windows should have been displayed.
see also bug 150028
Confounded helpful operating systems. I don't suppose a
kEventWindowBoundsChanging handler would easily fix all these not-so-hidden
window problems...

Bumping severity. If the hidden window is visible, the user can close it, and
that brings Mozilla down.
Severity: minor → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
bwahahahahahahahaahahahahahaha
I actually can't figure out how to close the window.  As I said in the initial
description, when I actually try to make the window active, it vanishes and I
get one of the real mozilla windows instead.  So I think this might be just a
cosmetic problem ...
Severity: major → minor
I would have expected that when the kWindowInWindowMenuAttribute flag isn't set
(which removes the window from the windowmenu), the OS would also make sure that
the window name doesn't appear on Exposé or in the dock (bug 150028).
I would like to know what this hidden window is for.
The hidden window owns the menu bar that displays when no other windows are open.
Isn't the easiest solution to make the window a palette instead of a full window? Those windows 
simply fade to nil during expose, and can't be minimized with option-click either.
*** Bug 233558 has been marked as a duplicate of this bug. ***
This occurs in the the new Firefox 0.8 as well.
Is there going to be a solution to this anytime soon?  When I first discovered it, I thought it was 
someone who had managed to sort out a way to bypass the popup blocker.  What about a 1 pixel 
window?
(In reply to comment #11)
> There's a hacky solution here:
> <http://cocoa.mamasam.com/COCOADEV/2004/02/1/83135.php>

This bug is only reproducible on a single display, the "hidden" window can't be
seen on multiple monitors.
There are reports from Thunderbird users about this hidden window (on the Polish
Mac users newsgroup, pl.comp.sys.macintosh, Message-ID: c8im6f$un6$1@news.atman.pl)
This bug is still there on the new 0.9 release.  Anyone have any new information
on this?
gte733z@prism.gatech.edu: generally people post new information. given comment
11, why don't you just write a patch?

(i'll probably write a patch for cocoa, so please don't complain to me.)
(In reply to comment #17)
> gte733z@prism.gatech.edu: generally people post new information. given comment
> 11, why don't you just write a patch?
> 
> (i'll probably write a patch for cocoa, so please don't complain to me.)

Have you already started your patch? Perhaps we can collaborate, no point in
doing duplicate work.  Also, I was under the impression the OSX portions of
Firefox was written in Carbon?  Thanks
i'll be writing my patch for cocoa which happens to be used by camino (you can
build firefox against cocoa but it isn't recommended and doesn't work very
well). no i haven't started, i haven't made it home [to my mac...] in a few days
(too much work).

there isn't much on which to collaborate. from the looks of it, the carbon
implementation requires you to get an api which will give you a windownumber
(good luck), after that it should be relatively downhill.
> i'll be writing my patch for cocoa which happens to be used by camino

There's no point. Camino doesn't make any XUL windows, so the hidden window
stuff doesn't apply, and Mozilla doesn't ship any XUL apps that use the Cocoa
toolkit.
blah, i new that was wrong right after i posted it. i'll still look into it (yes
i know xul-cocoa is broken, i might pick it up), it'll still be easier for me to
play with.
I have a patch to do the CGSTagSticky hack, but that doesn't block the movement
of the window during Exposé's "Show Windows", only during "Show Desktop". We'll
need something else.
Attached patch v1 (obsolete) — Splinter Review
This "hack" seems to work. The hidden window isn't exposed in the window list,
you can't cycle into it and it doesn't appear through option-minimize or
Exposé.
Attachment #154474 - Flags: review?(sfraser)
Looks OK, but it would be nice to replace all the NewCWindow calls with
CreateNewWindow.
Attached patch v2 (diff -w) (obsolete) — Splinter Review
Assignee: general → peterv
Attachment #154474 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Comment on attachment 155177 [details] [diff] [review]
v2 (diff -w)

I think I handled all cases correctly, but the old code was spread out so it's
hard to know for sure. I tried to simplify it by setting all the attributes
upfront. Note that I'm not at all sure about the replacement for plainDBox.
Attachment #155177 - Attachment description: v2 → v2 (diff -w)
Attachment #155177 - Flags: review?(sfraser)
Attached patch v2 (obsolete) — Splinter Review
Attachment #154474 - Flags: review?(sfraser)
Comment on attachment 155177 [details] [diff] [review]
v2 (diff -w)

Terrific patch!  Some comments:

+      default:
+	 windowClass = kDocumentWindowClass;
+	 attributes = kWindowCollapseBoxAttribute;
+	 if (allOrDefault || aInitData->mBorderStyle & eBorderStyle_close)
+	   attributes |= kWindowCloseBoxAttribute;
+	 break;
     }

Is this ever hit?  It seems to me that you've covered all of the cases except
for eWindowType_java, and that one doesn't seem to be used anywhere in the
code.  Might it not be better to the 'default' case assert, in case a new type
is added or eWindowType_java is actually used?

Since you removed some of the "#if TARGET_CARBON" lines, you may as well remove
the use of "nsToolkit::OnMacOSX()".
*** Bug 223779 has been marked as a duplicate of this bug. ***
*** Bug 150028 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0mac?
Bug 223779 (which is now duped to this) had blocking-aviary1.0mac+
Attachment #155177 - Flags: superreview?(sfraser)
Attachment #155177 - Flags: review?(sfraser)
Attachment #155177 - Flags: review?(jhpedemonte)
(In reply to comment #28)
> Is this ever hit?  It seems to me that you've covered all of the cases except
> for eWindowType_java, and that one doesn't seem to be used anywhere in the
> code.  Might it not be better to the 'default' case assert, in case a new type
> is added or eWindowType_java is actually used?

Yeah, I'll do this.

> Since you removed some of the "#if TARGET_CARBON" lines, you may as well remove
> the use of "nsToolkit::OnMacOSX()".

Will do.
Setting blocking-aviary1.0mac properly.
Flags: blocking-aviary1.0mac?
Flags: blocking-aviary1.0mac+
Comment on attachment 155177 [details] [diff] [review]
v2 (diff -w)

Just tried to build Firefox with the 10.2.8 SDK (as it is normally built), and
I got several build breaks.
First, kSimpleWindow is not defined until the 10.3 SDK, even though the
documentation says that it is available in 10.1+.
Second, kWindowDoesNotCycleAttribute is not available until 10.3.  We may have
to check for 10.3 and only enable it then.  Or define it ourselves and just set
it for all versions; maybe 10.1 and 10.2 will just ignore it.  I don't have
either to test on, though.
Attachment #155177 - Flags: review?(jhpedemonte) → review-
Attached patch v3 (diff -w)Splinter Review
Attachment #155177 - Attachment is obsolete: true
Attachment #155179 - Attachment is obsolete: true
Attached patch v3Splinter Review
Attachment #155177 - Flags: superreview?(sfraser)
Attachment #155967 - Flags: review?(jhpedemonte)
Comment on attachment 155967 [details] [diff] [review]
v3 (diff -w)

+    // XXX Need to special-case for OS X versions below 10.1, because
+    //     kSimpleWindowClass doesn't exist.
+    if (mWindowType == eWindowType_popup &&
+	 nsToolkit::OSXVersion() < MAC_OS_X_VERSION_10_1)
+    {
+      mWindowPtr = ::NewCWindow(nil, &wRect, "\p", false, kWindowSimpleProc,
+				 (WindowRef)-1, false, (long)nsnull);
+    }
+    else
+    {
+      ::CreateNewWindow(windowClass, attributes, &wRect, &mWindowPtr);
+    }

The system requirements for Mozilla on Mac start at OS X 10.1, so you can get
rid of the NewCWindow call.  Otherwise, it looks great.  Thanks.
Attachment #155967 - Flags: review?(jhpedemonte) → review+
Is it possible someone can post a binary build with this patch?
Hmm, we allow running on OS X below 10.1, we just warn on startup.
Attachment #155967 - Flags: superreview?(bryner)
Attachment #155967 - Flags: superreview?(bryner) → superreview+
Comment on attachment 155967 [details] [diff] [review]
v3 (diff -w)

Asking approval for aviary so we can get it in for PR1.
Attachment #155967 - Flags: approval-aviary?
I think the cmd-~ issue can be fixed by handling the
kHICommandRotateWindowsForward command.
The attached patch already fixes the window cycling issue.
Comment on attachment 155967 [details] [diff] [review]
v3 (diff -w)

a=asa for aviary checkin.
Attachment #155967 - Flags: approval-aviary? → approval-aviary+
Flags: blocking-aviary1.0PR?
Whiteboard: [have patch], needed-aviary1.0, patched approved for aviary
Checked into Aviary, will check into trunk soon.
Flags: blocking-aviary1.0PR?
Keywords: fixed-aviary1.0
Whiteboard: [have patch], needed-aviary1.0, patched approved for aviary
(In reply to comment #44)

We may want it for 1.7.3 as well.
Comment on attachment 155967 [details] [diff] [review]
v3 (diff -w)

Peterv already checked this into the trunk.  Asking for 1.7.3 approval.
Attachment #155967 - Flags: approval1.7.x?
Whiteboard: [fixed on trunk]
I'm seeing a huge regression in both Seamonkey and Firefox versions of today :
see bug 257546 comment 2 (I thought it was related to bug 257546). Most pulldown
menus are displayed in the top-left corner. Is it related to this path ? I
wasn't visible yesterday, the builds just before this patch.

I'm running Mac Os X 10.2.8

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040831

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040831
Firefox/0.9.1+
File a separate bug on that please. I don't see these regressions in a debug
SeaMonkey build from today on OS X 10.3.5.
(In reply to comment #48)
> File a separate bug on that please. I don't see these regressions in a debug
> SeaMonkey build from today on OS X 10.3.5.

bug 257647
(In reply to comment #49)
> (In reply to comment #48)
> > File a separate bug on that please. I don't see these regressions in a debug
> > SeaMonkey build from today on OS X 10.3.5.
> 
> bug 257647
> 

As i mentioned there, it is not repro on 10.3+.

Can anybody check if fixing "just" the version check to > 10.2 instead of >=
10.2 changes something? (I didn't read the whole patch, so it is nothing more
than a guess).

this needs to be backed out on the aviary and 1.7 branches until we can figure
out how to address  bug 257647

peter/jhpedemonte  can you help?
Flags: blocking-aviary1.0PR+
I'm backing it out. I'll need a 10.2 system to debug to find a fix.
Backed out of the aviary branch. I'm leaving this on the trunk for now. It's not
in 1.7.
Keywords: fixed-aviary1.0
Attachment #155967 - Flags: approval1.7.x?
(In reply to comment #53)

Clearing blocking flag.
Flags: blocking-aviary1.0PR+
*** Bug 259158 has been marked as a duplicate of this bug. ***
Has this bug been fixed?
The web site http://www.squarefree.com/burningedge/bigger-picture.html
says so, but I still see the hidden window in 0.10pr
(In reply to comment #56)
> Has this bug been fixed?
> The web site http://www.squarefree.com/burningedge/bigger-picture.html
> says so, but I still see the hidden window in 0.10pr

It was fixed, but backed out again for bug 257647 (see comment 53). That bug has
already a patch, so this one will be checked in again soon.
*** Bug 259919 has been marked as a duplicate of this bug. ***
Comment on attachment 155967 [details] [diff] [review]
v3 (diff -w)

Asking for branch approval again. This patch on its own caused one regression
for which there is now a patch (in bug 257647). I'm asking for approval of both
patches. I'm not aware of any other regressions because of this patch (it's
been on the trunk for nearly three weeks).
Attachment #155967 - Flags: approval-aviary+ → approval-aviary?
Comment on attachment 155967 [details] [diff] [review]
v3 (diff -w)

a=asa for aviary checkin.
Attachment #155967 - Flags: approval-aviary? → approval-aviary+
Checked into aviary branch.  -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
do we want it for 1.7 branch as well?
*** Bug 244559 has been marked as a duplicate of this bug. ***
*** Bug 264251 has been marked as a duplicate of this bug. ***
*** Bug 264827 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Status: RESOLVED → VERIFIED
We want this for 1.7.5. This is the single biggest win we can hand our Mac users
at this time.
Flags: blocking1.7.5+
Keywords: fixed1.7.5
You need to log in before you can comment on or make changes to this bug.