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

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.

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

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.

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!

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.

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.

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.

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

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

I borrowed the fix for GetTopLevelHWND for bug 297561.

Comment on attachment 191519 [details] [diff] [review] diff -d -u -20 approved for checkin, please land before midnight Pacific.

Comment on attachment 191519 [details] [diff] [review] diff -d -u -20 a=shaver/cbeard, please commit before branch (midnight Pacific)

I checked this in. Thanks Dainis!