XUL elements cannot be stacked on top of browser element

VERIFIED FIXED

Status

()

Core
XUL
P5
normal
VERIFIED FIXED
15 years ago
9 years ago

People

(Reporter: Jens Bannmann, Assigned: roc)

Tracking

({helpwanted, testcase})

Trunk
x86
Windows 2000
helpwanted, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

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

15 years ago
Created attachment 122362 [details]
xul file demonstrating the problem
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

Comment 4

15 years ago
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...
(Reporter)

Comment 6

15 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

14 years ago
Is there still work going on on this issue? If so, what is the state?
(Reporter)

Comment 8

14 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

14 years ago
Keywords: helpwanted

Updated

14 years ago
Blocks: 242621
(Reporter)

Comment 9

14 years ago
roc, do you have any idea how to fix this?
I'm planning to fix this as part of bug 78087.
(Reporter)

Updated

14 years ago
Depends on: 78087
No longer depends on: 130078

Updated

14 years ago
No longer blocks: 242621

Comment 11

14 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

13 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.)
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: 12 years ago
Keywords: testcase
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
Depends on: 317375

Comment 16

12 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)
I guess bug 130078 will take care of that.
Created attachment 215758 [details]
screenshot

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).

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets

Comment 20

9 years ago
Created attachment 387615 [details]
xulrunner application which shows the bug

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

9 years ago
Created attachment 387616 [details]
screenshot : xulrunner application

Comment 22

9 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.