542 bytes, application/vnd.mozilla.xul+xml
128.57 KB, image/png
2.85 KB, application/x-zip
57.63 KB, image/png
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 When using a stack to draw XUL elements on top of each other, the browser element behaves special. I know there were several related bugs a while ago, but this issue seems distinct from them, and also persists until today. (If there is an open bug on exactly this issue, I wasn't able to find it.) Reproducible: Always Steps to Reproduce: 1. Load the attached xul page Actual Results: The red label is in front of the green, but behind the browser. Expected Results: The red label should be in front of both the green label and the browser (since these two are in the same box and defined before the green label). This prevents extensions from displaying anything on top of the browser (like your TV does with the current programme's number), which would be quite useful in numerous cases.
roc, sounds like a dup of that "views screw up paint order" thing.... Perhaps all kids of a stack should get a view?
No, actually this only depends on hooking all the chrome shells into the common view hierarchy. Which is just a matter of deleting a few lines of code and then testing very carefully...
Assignee: hyatt → roc+moz
Status: UNCONFIRMED → NEW
Depends on: 130078
Ever confirmed: true
Priority: -- → P5
Bug 216835 seems a duplicate of this bug.
Oh, bz was right. This depends on making things-with-views and things-without-views paint in the right order. I can't find my bug on that...
roc, did you have time to investigate on this issue? And why does this depend on bug 130078, which is about <iframe>, not <browser>? On bug 130078 comment 11, Wang said it doesn't affect this problem.
Is there still work going on on this issue? If so, what is the state?
Looks like roc didn't have the time for this; even in bug 130078 there was no activity since mid-2003...
roc, do you have any idea how to fix this?
I'm planning to fix this as part of bug 78087.
It seems this applies to <splitter>s as well, and has unfortunately prevented a neat solution to bug 265847 being done (won't stop me trying some other methods, though). While obviously not wishing to rush the process, it would be good to get this bug fixed as it limits some of the effects you can do with XUL. :)
(In reply to comment #10) > I'm planning to fix this as part of bug 78087. Roc, do you have any updates/guesstimates on this? (Sorry for the repeated bugging, I'm just really interested in this.)
This sounds related to bug 94687.
Testcase doesn't work with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060124 Firefox/1.6a1 ID:2006012405 ("just another label" is behind the browser) Testcase does work with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1 ID:2006012613 ("just another label" is on top of the browser) --> RESOLVED FIXED (by bug 317375)
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060126 Firefox/1.6a1 (1:19am tinderbox build). A bit strange, because it seems that this bug seems related/depends on bug 130078.
Status: RESOLVED → VERIFIED
Depends on: 130078
This still doesn't work with <tabbrowser/> though :( (And for my future reference - bug 313190 is also interesting for those who wish to stack things over Firefox's tabbrowser)
I guess bug 130078 will take care of that.
I have just hit this bug with xulrunner-1.9a1.en-US.win32.zip ... See screenshot attached. Roc, you checked in your fix for bug 78087 beginning of february but that xulrunner build is from the 22nd of feb according to ftp. Should this bug be reopened ?
Well, the testcase is fixed in current builds, that's what I tested it against with. I guess it can be reopened, but it's probably not so useful since the real fix to this is coming in bug 130078 (which might need a testcase that still reproduces the bug).
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
The bug is fixed when opening the .xul file in a browser, but not when used as a xulrunner application. I used xulrunner 188.8.131.52, I need to test if the bug is also there with 1.9.1.xx and 1.9.2.xx
(In reply to comment #20) > The bug is fixed when opening the .xul file in a browser, but not when used as > a xulrunner application. I used xulrunner 184.108.40.206, I need to test if the bug > is also there with 1.9.1.xx and 1.9.2.xx I just tested from a nightly build and reproduced the bug : Mozilla XULRunner 1.9.2a1pre - 20090708045522
You need to log in before you can comment on or make changes to this bug.