Closed Bug 300297 Opened 19 years ago Closed 19 years ago

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

Categories

(Core :: XUL, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: karl, Assigned: jag+mozilla)

References

Details

Attachments

(3 files)

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
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.
Status: UNCONFIRMED → NEW
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.
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. 
Status: NEW → ASSIGNED
Attached patch diff -d -u -20Splinter Review
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)
Flags: blocking1.8b4?
Attachment #191519 - Flags: superreview?(roc)
Attachment #191519 - Flags: superreview+
Attachment #191519 - Flags: review?(emaijala)
Attachment #191519 - Flags: review+
Drivers will evaluate fix, to see if it should go in beta.
Flags: blocking1.8b4? → blocking1.8b4-
Comment on attachment 191519 [details] [diff] [review]
diff -d -u -20

asking for approval
Attachment #191519 - Flags: approval1.8b4?
I borrowed the fix for GetTopLevelHWND for bug 297561.
Depends on: 297561
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 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!
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: