159410 - Popup windows do an ugly resize flash when shown, and can have unnecessary scrollbars

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[Simon Fraser [no longer active]]

when requested to show popup windows (with a window.open()), Chimera does an
ugly show-then-resize, and makes the window the wrong size (so that scroll bars
are shown when they should not be).

Comment 1

[Simon Fraser [no longer active]]

Attachment: Test image for testcase

Comment 2

[Simon Fraser [no longer active]]

Attachment: Testcase for popup windows.

Comment 3

[Mike Pinkerton (not reading bugmail)]

this is caused by our good friend -runModalSession: which calls
makeKeyAndOrderFront: on the window so we end up showing it before we're really
ready for it.

the only way i can see to get around this is to have BrowserWindow override
makeKeyAndOrderFront: and pick out the case with some member flags where we're
calling it from that. that won't be easy, though.

Comment 4

[Mike Pinkerton (not reading bugmail)]

*** Bug 164102 has been marked as a duplicate of this bug. ***

Comment 5

[Mike Pinkerton (not reading bugmail)]

ok, this is kicking my butt. i tried doing a lot of work to get around the fact
that the modal loop is showing the window, pushing it offscreen and bringing it
back on later, but that broke other things. i also tried to suppress the show
during the modal loop but that didn't work either. 

i'm stumped, short of coming up with a way to actually get rid of this modal
loop. we may have to burn an incident with apple. 

aaarrrrgh! :(

Comment 6

[Simon Fraser [no longer active]]

There's a really simple way to force the window nib loading to be synchronous:

   BrowserWindowController* browser = [[BrowserWindowController alloc]
initWithWindowNibName: @"BrowserWindow"];
+  [browser window];		// force sync window loading

then we can ditch all that skanky modal session stuff.

Comment 7

[Simon Fraser [no longer active]]

Taking.

Comment 8

[Simon Fraser [no longer active]]

Attachment: Patch to eliminate modal session, and fix background window loads

This patch eliminates the modal session stuff, which we don't need if we force
synchronous window creation after allocating the window controller with a call
to [winController window].

Now that we don't have enterModalSession to show the window for us, we have to
rely on gecko calling CHBrowserListener::SetVisibility() (which is will, after
resizing the window).

CHBrowserListener::SetVisibility() in turn needed fixing so that windows loaded
in the background don't pop to the front when gecko focusses their contents. I
use a flag on the browser window to determine whether SetVisibility() should
order the window to the front or not.

Note that you'll want the patch in bug 178010 to prevent pages that focus a
form element (e.g. google.com) from bringing background windows to the front on
load.

Comment 9

[Simon Fraser [no longer active]]

I think we also want this change in GetVisibility():

 /* attribute boolean visibility; */
 NS_IMETHODIMP 
 CHBrowserListener::GetVisibility(PRBool *aVisibility)
 {
   NS_ENSURE_ARG_POINTER(aVisibility);
 
   if (!mView) {
     return NS_ERROR_FAILURE;
   }
 
   NSWindow* window = [mView window];
   if (!window) {
     return NS_ERROR_FAILURE;
   }
 
-  *aVisibility = [window isMiniaturized];
+  *aVisibility = [window isVisible];
 
   return NS_OK;
 }

Comment 10

[Simon Fraser [no longer active]]

Checked in.

Comment 11

[Greg K.]

*** Bug 178587 has been marked as a duplicate of this bug. ***

Comment 12

[Greg K.]

*** Bug 168486 has been marked as a duplicate of this bug. ***

Comment 13

[sairuh (rarely reading bugmail)]

vrfy'd fixed, mostly: no longer get the nasty flashing resize, but small popups
still have scrollbars. filed bug 180406 for that.

tested on 10.2.2 with 2002.11.15.04.