The default bug view has changed. See this FAQ.

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

VERIFIED FIXED

Status

SeaMonkey
General
--
minor
VERIFIED FIXED
14 years ago
9 years ago

People

(Reporter: Matt McHenry, Assigned: peterv)

Tracking

({fixed-aviary1.0, fixed1.7.5})

Trunk
PowerPC
Mac OS X
fixed-aviary1.0, fixed1.7.5
Bug Flags:
blocking1.7.5 +
blocking-aviary1.0mac +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed on trunk])

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Created attachment 134039 [details]
screenshot including the extra "hidden" window

Comment 2

14 years ago
see also bug 150028

Comment 3

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

Updated

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
bwahahahahahahahaahahahahahaha
(Reporter)

Comment 5

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

Comment 6

14 years ago
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).

Comment 7

14 years ago
I would like to know what this hidden window is for.

Comment 8

14 years ago
The hidden window owns the menu bar that displays when no other windows are open.

Comment 9

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

Comment 11

13 years ago
There's a hacky solution here:
<http://cocoa.mamasam.com/COCOADEV/2004/02/1/83135.php>

Comment 12

13 years ago
This occurs in the the new Firefox 0.8 as well.

Comment 13

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

Comment 14

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

Comment 16

13 years ago
This bug is still there on the new 0.9 release.  Anyone have any new information
on this?

Comment 17

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

Comment 18

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

Comment 19

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

Comment 20

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

Comment 21

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

Comment 22

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

Comment 23

13 years ago
Created attachment 154474 [details] [diff] [review]
v1

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é.
(Assignee)

Updated

13 years ago
Attachment #154474 - Flags: review?(sfraser)

Comment 24

13 years ago
Looks OK, but it would be nice to replace all the NewCWindow calls with
CreateNewWindow.
(Assignee)

Comment 25

13 years ago
Created attachment 155177 [details] [diff] [review]
v2 (diff -w)
(Assignee)

Updated

13 years ago
Assignee: general → peterv
Attachment #154474 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(Assignee)

Comment 26

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

Comment 27

13 years ago
Created attachment 155179 [details] [diff] [review]
v2
(Assignee)

Updated

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

Updated

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

Comment 31

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

Comment 32

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

Comment 35

13 years ago
Created attachment 155967 [details] [diff] [review]
v3 (diff -w)
Attachment #155177 - Attachment is obsolete: true
Attachment #155179 - Attachment is obsolete: true
(Assignee)

Comment 36

13 years ago
Created attachment 155968 [details] [diff] [review]
v3
(Assignee)

Updated

13 years ago
Attachment #155177 - Flags: superreview?(sfraser)
(Assignee)

Updated

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

Comment 38

13 years ago
Is it possible someone can post a binary build with this patch?
(Assignee)

Comment 39

13 years ago
Hmm, we allow running on OS X below 10.1, we just warn on startup.
(Assignee)

Updated

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

Comment 41

13 years ago
I think the cmd-~ issue can be fixed by handling the
kHICommandRotateWindowsForward command.
The attached patch already fixes the window cycling issue.

Comment 43

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

Comment 47

13 years ago
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+
(Assignee)

Comment 48

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

Comment 49

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

Comment 51

13 years ago
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+
(Assignee)

Comment 52

13 years ago
I'm backing it out. I'll need a 10.2 system to debug to find a fix.
(Assignee)

Comment 53

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

Updated

13 years ago
Attachment #155967 - Flags: approval1.7.x?
(In reply to comment #53)

Clearing blocking flag.
Flags: blocking-aviary1.0PR+

Comment 55

13 years ago
*** Bug 259158 has been marked as a duplicate of this bug. ***

Comment 56

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

Comment 57

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

Comment 58

13 years ago
*** Bug 259919 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 59

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

13 years ago
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
Last Resolved: 13 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
do we want it for 1.7 branch as well?

Comment 63

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

Comment 66

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

Updated

13 years ago
Keywords: fixed1.7.5
You need to log in before you can comment on or make changes to this bug.