Closed
Bug 223545
Opened 20 years ago
Closed 20 years ago
Mac OS X 10.3's expose feature reveals "hidden" window
Categories
(SeaMonkey :: General, defect)
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)
178.86 KB,
image/jpeg
|
Details | |
24.10 KB,
patch
|
jhpedemonte
:
review+
bryner
:
superreview+
asa
:
approval-aviary+
|
Details | Diff | Splinter Review |
26.01 KB,
patch
|
Details | Diff | Splinter Review |
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•20 years ago
|
||
Comment 2•20 years ago
|
||
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
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•20 years ago
|
||
bwahahahahahahahaahahahahahaha
Reporter | ||
Comment 5•20 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•20 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•20 years ago
|
||
I would like to know what this hidden window is for.
Comment 8•20 years ago
|
||
The hidden window owns the menu bar that displays when no other windows are open.
Comment 9•20 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.
Comment 10•20 years ago
|
||
*** Bug 233558 has been marked as a duplicate of this bug. ***
Comment 11•20 years ago
|
||
There's a hacky solution here: <http://cocoa.mamasam.com/COCOADEV/2004/02/1/83135.php>
Comment 12•20 years ago
|
||
This occurs in the the new Firefox 0.8 as well.
Comment 13•20 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•20 years ago
|
||
This bug is only reproducible on a single display, the "hidden" window can't be seen on multiple monitors.
Comment 15•20 years ago
|
||
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•20 years ago
|
||
This bug is still there on the new 0.9 release. Anyone have any new information on this?
Comment 17•20 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•20 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•20 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•20 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•20 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•20 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•20 years ago
|
||
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•20 years ago
|
Attachment #154474 -
Flags: review?(sfraser)
Comment 24•20 years ago
|
||
Looks OK, but it would be nice to replace all the NewCWindow calls with CreateNewWindow.
Assignee | ||
Comment 25•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Assignee | ||
Comment 26•20 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•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #154474 -
Flags: review?(sfraser)
Comment 28•20 years ago
|
||
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()".
Comment 29•20 years ago
|
||
*** Bug 223779 has been marked as a duplicate of this bug. ***
Comment 30•20 years ago
|
||
*** Bug 150028 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0mac?
Comment 31•20 years ago
|
||
Bug 223779 (which is now duped to this) had blocking-aviary1.0mac+
Updated•20 years ago
|
Attachment #155177 -
Flags: superreview?(sfraser)
Attachment #155177 -
Flags: review?(sfraser)
Attachment #155177 -
Flags: review?(jhpedemonte)
Assignee | ||
Comment 32•20 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.
Comment 33•20 years ago
|
||
Setting blocking-aviary1.0mac properly.
Flags: blocking-aviary1.0mac?
Flags: blocking-aviary1.0mac+
Comment 34•20 years ago
|
||
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•20 years ago
|
||
Attachment #155177 -
Attachment is obsolete: true
Attachment #155179 -
Attachment is obsolete: true
Assignee | ||
Comment 36•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #155177 -
Flags: superreview?(sfraser)
Assignee | ||
Updated•20 years ago
|
Attachment #155967 -
Flags: review?(jhpedemonte)
Comment 37•20 years ago
|
||
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•20 years ago
|
||
Is it possible someone can post a binary build with this patch?
Assignee | ||
Comment 39•20 years ago
|
||
Hmm, we allow running on OS X below 10.1, we just warn on startup.
Assignee | ||
Updated•20 years ago
|
Attachment #155967 -
Flags: superreview?(bryner)
Updated•20 years ago
|
Attachment #155967 -
Flags: superreview?(bryner) → superreview+
Comment 40•20 years ago
|
||
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•20 years ago
|
||
I think the cmd-~ issue can be fixed by handling the kHICommandRotateWindowsForward command.
Comment 42•20 years ago
|
||
The attached patch already fixes the window cycling issue.
Comment 43•20 years ago
|
||
Comment on attachment 155967 [details] [diff] [review] v3 (diff -w) a=asa for aviary checkin.
Attachment #155967 -
Flags: approval-aviary? → approval-aviary+
Updated•20 years ago
|
Flags: blocking-aviary1.0PR?
Whiteboard: [have patch], needed-aviary1.0, patched approved for aviary
Comment 44•20 years ago
|
||
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
Comment 45•20 years ago
|
||
(In reply to comment #44) We may want it for 1.7.3 as well.
Comment 46•20 years ago
|
||
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?
Updated•20 years ago
|
Whiteboard: [fixed on trunk]
Comment 47•20 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•20 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•20 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
Comment 50•20 years ago
|
||
(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•20 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•20 years ago
|
||
I'm backing it out. I'll need a 10.2 system to debug to find a fix.
Assignee | ||
Comment 53•20 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•20 years ago
|
Attachment #155967 -
Flags: approval1.7.x?
Comment 54•20 years ago
|
||
(In reply to comment #53) Clearing blocking flag.
Flags: blocking-aviary1.0PR+
Comment 55•20 years ago
|
||
*** Bug 259158 has been marked as a duplicate of this bug. ***
Comment 56•20 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•20 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•20 years ago
|
||
*** Bug 259919 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 59•20 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•20 years ago
|
||
Comment on attachment 155967 [details] [diff] [review] v3 (diff -w) a=asa for aviary checkin.
Attachment #155967 -
Flags: approval-aviary? → approval-aviary+
Comment 61•20 years ago
|
||
Checked into aviary branch. -> FIXED
Comment 62•20 years ago
|
||
do we want it for 1.7 branch as well?
Comment 63•19 years ago
|
||
*** Bug 244559 has been marked as a duplicate of this bug. ***
Comment 64•19 years ago
|
||
*** Bug 264251 has been marked as a duplicate of this bug. ***
Comment 65•19 years ago
|
||
*** Bug 264827 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Product: Browser → Seamonkey
Updated•19 years ago
|
Status: RESOLVED → VERIFIED
Comment 66•19 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•19 years ago
|
Keywords: fixed1.7.5
You need to log in
before you can comment on or make changes to this bug.
Description
•