298072 - hidechrome window drawing problem

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Anand Aiyer]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: 

There is a problem when drawing a XUL window with hidechrome enabled where the 
child window is smaller in size than a parent window container that mozilla 
draws, exhibiting in strange behaviour.

If I resize the window a resizer element, the child window restores to the 
size of the parent window and the behaviour afterwares is ok.


Reproducible: Always

Comment 1

[Anand Aiyer]

Attachment: A screenshot of what happens.

Comment 2

[Anand Aiyer]

Attachment: A testcase.

Comment 3

[Anand Aiyer]

Attachment: patch

Comment 4

[Anand Aiyer]

The above patch fixes it. It sets the window without chrome before the sizes 
is set, so that the client area is correctly calcualted.

Comment 5

[mig]

I see this bug too.  Hopefully, two pair of eyes will take this bug off of
"UNCONFIRMED" status.

The "off-blit" sections of the window seem to correspond exactly to the sizes of
the titlebar and window borders for a "normal" win32 window.

Interestingly, if I set the size of my <window> element through xml attributes,
the actual OS window created is that size, but my own art only blits into a
portion of the window and the "off blit" section is along the bottom and right
edges.

However, if I set the size from CSS, my own art blits to the proper size
specified in the CSS but my OS window is larger and the "off blit" section is
still on the bottom and right.

Comment 6

[Brendan Eich [:brendan]]

Cc'ing people is always good.  Confirming base don mig's testimony.

/be

Comment 7

[Benjamin Smedberg]

Comment on attachment 187265 [details] [diff] [review]
patch

I'll land this.

Comment 8

[Benjamin Smedberg]

Fixed on trunk for 1.8b4

Comment 9

[mig]

This bug seems to also happen when I call window.resizeTo, now  :(

I'll make a new entry.