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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: karl, Assigned: jag+mozilla)
References
Details
Attachments
(3 files)
28.51 KB,
application/x-xpinstall
|
Details | |
918 bytes,
application/vnd.mozilla.xul+xml
|
Details | |
6.72 KB,
patch
|
roc
:
review+
roc
:
superreview+
cbeard
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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
Updated•19 years ago
|
Assignee: nobody → jag
Component: General → XP Toolkit/Widgets
Product: Firefox → Core
QA Contact: general → jrgmorrison
Version: unspecified → Trunk
Comment 2•19 years ago
|
||
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.
Updated•19 years ago
|
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.
Comment 5•19 years ago
|
||
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•19 years ago
|
||
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•19 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.
Status: NEW → ASSIGNED
Comment 8•19 years ago
|
||
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)
Updated•19 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•19 years ago
|
||
Drivers will evaluate fix, to see if it should go in beta.
Flags: blocking1.8b4? → blocking1.8b4-
Comment 10•19 years ago
|
||
Comment on attachment 191519 [details] [diff] [review] diff -d -u -20 asking for approval
Attachment #191519 -
Flags: approval1.8b4?
Comment 12•19 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•19 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!
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.
Description
•