204278 - XUL elements cannot be stacked on top of browser element

Status: VERIFIED FIXED

(Core :: XUL, defect, P5)

Description

[Jens Bannmann]

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.

Comment 1

[Jens Bannmann]

Attachment: xul file demonstrating the problem

Comment 2

[Boris Zbarsky [:bzbarsky]]

roc, sounds like a dup of that "views screw up paint order" thing.... Perhaps
all kids of a stack should get a view?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 4

[Wang Xianzhu]

Bug 216835 seems a duplicate of this bug.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 6

[Jens Bannmann]

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

[Jan Schukat]

Is there still work going on on this issue? If so, what is the state?

Comment 8

[Jens Bannmann]

Looks like roc didn't have the time for this; even in bug 130078 there was no
activity since mid-2003...

Comment 9

[Jens Bannmann]

roc, do you have any idea how to fix this?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm planning to fix this as part of bug 78087.

Comment 11

[James Ross]

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

Comment 12

[Jens Bannmann]

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

Comment 13

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

This sounds related to bug 94687.

Comment 14

[Steve England [:stevee]]

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

[Martijn Wargers (dead)]

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.

Comment 16

[Nickolay_Ponomarev]

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

[Martijn Wargers (dead)]

I guess bug 130078 will take care of that.

Comment 18

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: 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 ?

Comment 19

[Martijn Wargers (dead)]

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

Comment 20

[Thomas Bernard]

Attachment: 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

[Thomas Bernard]

Attachment: screenshot : xulrunner application

Comment 22

[Thomas Bernard]

(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