70388 - Showing hidden window causes problems on OSX

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Mike Pinkerton (not reading bugmail)]

On OSX, beard says that you can't show a window with no size or things freak out. 
Our 'hidden window' is just such a window. In the last carbon landing, beard put 
in a patch to nsMacWindow::Show() that would not show a window unless it has a 
non-zero size. However, this broke menu processing in classic because we rely on 
the hidden window being available to ::FrontWindow() when there are no other 
windows. Although it has no size, it is visible (we called ::ShowWindow on it) so 
::FrontWindow finds it.

We need a solution that works in both worlds. Maybe Apple fixed the no-size bug 
in later versions of OSX, though I'd doubt it. Perhaps we should raise this issue 
on CarbonIT.

Comment 1

[Mike Pinkerton (not reading bugmail)]

one solution might be to do something like the menu code does (though beard hates 
this, i know) and remember the first window we see (which will be the hidden 
window...i hope, what about profile manager?) and then try that when 
::FindWindow() returns no visible window?

or we can check an attribute on every window tag at construction time and use 
that to indicate the special hidden window and cache its WindowPtr. Then it could 
be any window.

Just throwing out ideas.

Comment 2

[Mike Pinkerton (not reading bugmail)]

i just tried our latest OSX seed and windows with no size still hang the app. 
should we bother reporting this to apple?

Comment 3

[Adam]

> should we bother reporting this to apple?



Absolutely, yes. There might not be anything they can do about it at this stage 

(if it still exists in the latest builds), but that's no reason not to report it. 

At best, they'll tell you it's fixed already, at worst, they'll be aware of it 

and can fix it in the next Carbon/OS X update.

Comment 4

[Mike Pinkerton (not reading bugmail)]

i have a fix that keeps the hidden window visible (but offscreen) so we don't 
need any special case focus code to set the menu bar (the normal activate code 
does it for us).

Comment 5

[Mike Pinkerton (not reading bugmail)]

Attachment: [patch] patch to make hidden window visible, but waay offscreen to get around special case code

Comment 6

[Mike Pinkerton (not reading bugmail)]

i need help verifying that all this is ok on win32 and linux. I expect it is, 
but...if not, we can always ifdef XP_MAC the code that shows the hidden window.

danm? can you lend me a hand with win32 patch-fu?

Comment 7

[Mike Pinkerton (not reading bugmail)]

Attachment: [patch] take2, last one was malformed

Comment 8

[Mike Pinkerton (not reading bugmail)]

osx seems to have issues placing the window at -32000, -32000. moving it to -
10000,-10000 seemed to work better.

Comment 9

[Simon Fraser [no longer active]]

Is  there any way we can keep the content for the hidden window, but never make a 
WindowPtr for it? Never making a window would avoid some of these issues.

Comment 10

[Mike Pinkerton (not reading bugmail)]

i'd like to try to get this landed. 

i think i already addressed sfraser's last comment about not actually creating a
windowPtr. Doing so allows us to remove the special case code and uses the OS to
send us the right events to switch the menu bar.

I've been running with the patch and haven't noticed any problems with dialogs
coming up offscreen or in weird places.

damn? can you apply this on linux for me and let me know if there are any
problems there?

Comment 11

[Dan M]

  My patch juju seems to have expired. Even waterson's patch lore was unhelpful. 
So I didn't actually try the patch. I did scan through the source for problems, 
though. My worry is that windows using HiddenWindow for their parent (that's 
evil, but not uncommon) will naturally try to position themselves offscreen with 
their parent. We need to be sure there's an override.
  The Linux, Mac and Windows builds all claim to force a window onscreen, so 
they're probably all safe enough. Other ports could have troubles. Most windows 
have some sort of specific positional override. I found three exceptions. You 
wouldn't notice any of them under normal conditions, and I have little faith that 
I found all of them. But like I said, it probably won't affect the three main 
ports. Ahem.
  The mail/news exceptions, for instance, you wouldn't notice unless you were 
using a new profile. I'd feel safer if you included in your patch the extra bits 
I've attached below.
  Blast. We really should just give it a run on Windows and Linux before checking 
in. Look for funny window activation problems now that the window is visible, and 
all. Grrr. !%!$ patch. Continued, tomorrow...

Comment 12

[Dan M]

Attachment: three sons of hidden window which don't explicitly position themselves

Comment 13

[David Hyatt]

sr=hyatt, but ifdef XP_MAC the showing of the hidden window (setting the
visibility to true).

Comment 14

[Mike Pinkerton (not reading bugmail)]

fixed.

Comment 15

[Chris Petersen]

Marking verified in the June 13th (2001061314) build.