300297 - transparent dependent xul window opened from chrome causes browser window to be redraw as transparent window in Deer Park

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[karl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+

If you attempt to open a dependent window from the chrome (
using window.open('transparent_window.xul','','chrome,dependent');
) then the new window is created and the main browser window is resized and
redrawn the same at the transparent window.

Reproducible: Always

Steps to Reproduce:
1. download and install the transparent_window_bug.xpi from
http://www.werehamster.net/xpi/transparent_window_bug.xpi
2. restart browser so xpi is installed
3. click the new menu items transparent_window_bug/open dependent transparent

Actual Results:  
the main browser window resizes to the size of the new (transparent) window.
the main browser window is repainted to look like the transparent window and
refuses to change. You loose all of the chrome (including
minimize/maximize/close buttons) in the main browser window.


Expected Results:  
the transparent window should open normally and the main browser window should
be unaffected.

I don't know if it's relevant but I'm using an nVidia GeForce4 MX 440 video card

Comment 1

[karl]

Attachment: the xpi to replicate the bug

Comment 2

[Martijn Wargers (dead)]

I'm also getting problems with the "open dependent non-transparent" item.
The opened window seems to "take over" the title bar (the bar with
minimize/maximize/close buttons) and when I close it, the main browser window
has lost it's title bar.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

On GTK2 these windows aren't transparent at all, until you resize them. Hmm. I
wonder if it's my theme

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I do not see this bug on GTK2. Note that the testcase doesn't quite work on
GTK2; it's not enough to just set background:transparent, you also have to set
-moz-appearance:none to disable any theming.

I suspect a bug in the Windows code here, so I hope Dainis can help.

I do see a problem where we don't remove the window chrome in GTK2. I guess I
should fix that.

Comment 5

[Dainis Jonitis]

Karl,

Is the problem still present after Robert's changes? Can it be recreated on
Mozilla Seamonkey? Would be nice if you can update the testcase with things
Robert mentioned so that I can debug it from Seamonkey. I never built debug
versions of Firefox before and last time I tried it did not worked...
At the moment I have no enough spare time to look at it, but if you will provide
updated testcase for Seamonkey I will investigate the problem. Thanks!

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase (test it locally)

No need for an extension. You should be able to see the bug with this testcase.

You need to download this file to your hard drive and run it locally. When a
security warning appears, when clicking on the button, just accept it.

Comment 7

[Dainis Jonitis]

Martijn, thanks for testcase! I was able to debug the problem and simulate
correct behaviour under debugger. The problem is indeed Win32 widget code
specific. When looking for top level window we go too far in child->parent
chain. Will work on fix right now. 

Comment 8

[Dainis Jonitis]

Attachment: diff -d -u -20

The problem was in GetTopLevelHWND() function which was calling Win32 API
function ::GetParent(). This API function returns parent window if there is one
and owner window if there is no parent set. As result we were traversing too
far and always ended with the highest parent.
For our tasks we need to stop at the first window that is top-level in the
terms of Win32 API. Both WS_OVERLAPPED and WS_POPUP windows are the top-level
windows. It is easier to check for WS_CHILDWINDOW flag to determine that it is
not a top-level window.

Comment 9

[Corinne Bordelon]

Drivers will evaluate fix, to see if it should go in beta.

Comment 10

[Dainis Jonitis]

Comment on attachment 191519 [details] [diff] [review]
diff -d -u -20

asking for approval

Comment 11

[Ere Maijala (slow)]

I borrowed the fix for GetTopLevelHWND for bug 297561.

Comment 12

[Chris Beard]

Comment on attachment 191519 [details] [diff] [review]
diff -d -u -20

approved for checkin, please land before midnight Pacific.

Comment 13

[Chris Beard]

Comment on attachment 191519 [details] [diff] [review]
diff -d -u -20

a=shaver/cbeard, please commit before branch (midnight Pacific)

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I checked this in. Thanks Dainis!