Closed
Bug 204278
Opened 22 years ago
Closed 19 years ago
XUL elements cannot be stacked on top of browser element
Categories
(Core :: XUL, defect, P5)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jens.b, Assigned: roc)
References
Details
(Keywords: helpwanted, testcase)
Attachments
(4 files)
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.
Reporter | ||
Comment 1•22 years ago
|
||
Comment 2•22 years ago
|
||
roc, sounds like a dup of that "views screw up paint order" thing.... Perhaps
all kids of a stack should get a view?
Assignee | ||
Comment 3•22 years ago
|
||
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
Comment 4•21 years ago
|
||
Bug 216835 seems a duplicate of this bug.
Assignee | ||
Comment 5•21 years ago
|
||
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...
Reporter | ||
Comment 6•21 years ago
|
||
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.
Comment 7•21 years ago
|
||
Is there still work going on on this issue? If so, what is the state?
Reporter | ||
Comment 8•21 years ago
|
||
Looks like roc didn't have the time for this; even in bug 130078 there was no
activity since mid-2003...
Reporter | ||
Updated•21 years ago
|
Keywords: helpwanted
Reporter | ||
Comment 9•21 years ago
|
||
roc, do you have any idea how to fix this?
Assignee | ||
Comment 10•21 years ago
|
||
I'm planning to fix this as part of bug 78087.
Reporter | ||
Updated•21 years ago
|
Comment 11•20 years ago
|
||
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. :)
Reporter | ||
Comment 12•20 years ago
|
||
(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.
Comment 14•19 years ago
|
||
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)
Comment 15•19 years ago
|
||
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
Comment 16•19 years ago
|
||
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)
Comment 17•19 years ago
|
||
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 ?
Comment 19•19 years ago
|
||
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
Comment 20•16 years ago
|
||
The bug is fixed when opening the .xul file in a browser, but not when used as a xulrunner application. I used xulrunner 1.9.0.11, I need to test if the bug is also there with 1.9.1.xx and 1.9.2.xx
Comment 21•16 years ago
|
||
Comment 22•16 years ago
|
||
(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 1.9.0.11, 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.
Description
•