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




13 years ago
12 years ago


(Reporter: karl, Assigned: jag (Peter Annema))


Windows 2000
Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)



(3 attachments)



13 years ago
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 (
) 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
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

13 years ago
Created attachment 188874 [details]
the xpi to replicate the bug


13 years ago
Assignee: nobody → jag
Component: General → XP Toolkit/Widgets
Product: Firefox → Core
QA Contact: general → jrgmorrison
Version: unspecified → Trunk
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.


13 years ago
Ever confirmed: true
Attachment #188874 - Attachment mime type: application/octet-stream → application/x-xpinstall
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.

Comment 5

13 years ago

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!
Created attachment 191366 [details]
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

13 years ago
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

13 years ago
Created attachment 191519 [details] [diff] [review]
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.
Attachment #191519 - Flags: superreview?(roc)
Attachment #191519 - Flags: review?(emaijala)


13 years ago
Flags: blocking1.8b4?
Attachment #191519 - Flags: superreview?(roc)
Attachment #191519 - Flags: superreview+
Attachment #191519 - Flags: review?(emaijala)
Attachment #191519 - Flags: review+

Comment 9

13 years ago
Drivers will evaluate fix, to see if it should go in beta.
Flags: blocking1.8b4? → blocking1.8b4-

Comment 10

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

asking for approval
Attachment #191519 - Flags: approval1.8b4?

Comment 11

13 years ago
I borrowed the fix for GetTopLevelHWND for bug 297561.
Depends on: 297561

Comment 12

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

approved for checkin, please land before midnight Pacific.
Attachment #191519 - Flags: approval1.8b4? → approval1.8b4+

Comment 13

13 years ago
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!
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.