380192 - window resizing in script causes content to be drawn on top of toolbars and tabstrip chrome

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

Using a recent (as of May 9, 2007) nightly of Minefield on OSX, visiting the page in the URL field will cause the following behaviour:

1. Active window will be resized to a small window in the bottom right corner
2. JS alert asks to install antivirus software
3. After either answer to JS alert, the active window is restored with a bogus security audit result

In step 3, the content window is sized (apparently unintentionally) such that the top of the content is cut off, and it renders on top of the toolbars and tabstrip. Resizing the window brings things back to normal.

Core::Layout?

Comment 1

[:Gavin Sharp [email: [e-mail]]]

This looks like a problem with nsCocoaWindow::Resize, called from nsGlobalWindow::ResizeTo().

Comment 2

[Josh Aas]

Gavin - why do you say that?

Beltzner - can you attach a screenshot?

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #2)
> Gavin - why do you say that?

I'm assuming that's where the problem is because this is a Mac-specific problem with ResizeTo, and the call to the widget-level ::Resize() from nsXULWindow::SetPositionAndSize is where things start to get platform-specific.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Can you not reproduce the problem with the testcase in the URL field? It's easy to reproduce here, on our 15" MBPs, but perhaps it depends on our screen resolution/monitor size.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Attachment: screenshot

Notice the scrollbar on the right, you can't see the top because it's offscreen (as are the toolbars). Clicking the resizer and moving it 1 pixel "fixes" the problem (the toolbars come back into view).

Comment 7

[Josh Aas]

Attachment: fix v1.0

The native resize can have its size restricted, we should send the actual new window size in our resize event, not the requested size.

Comment 8

[Josh Aas]

landed on trunk

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Looks like this caused a pretty sizable Tp/Tp2 hit on bm-xserve08

Comment 10

[Josh Aas]

It seems very unlikely that this would have caused a Tp hit of any kind. None of the code is expensive and it only executes when the window resizes. There is really no other reasonable way to do this.