Closed Bug 471526 Opened 16 years ago Closed 3 years ago

Firefox 3 issues w/ z-index and plugins (such as Flash and VLC), plugins hidden or hiding inconsistantly

Categories

(Core :: Layout, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: yannack, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.5) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.5) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5

Hello,
I am trying to have Firefox display various elements, including some using external plugins (Adobe Flash, VLC http://www.videolan.org). However, these do not obey z-index rules properly. Different ways of setting things up lead to different results, non of which are correct (I use setTimeout to decide which element appears first)
1. I embed the VLC plugin and display an image in a DIV. -> VLC is always in front of the image, regardless of zIndexes (and regardless of which element is added to the document first)
2. I display a Flash animation as the source of an IFRAME and an image in a DIV. -> Flash is always in front of the image, regardless of zIndexes and which one is added to the document first (no wmode parameter choice possible in this option, since src=foo.swf doesn't allow wmode setting)
3. I embed the VLC plugin and embed a Flash animation. -> VLC is always in front of the Flash animation, regardless of zIndexes and which one is added to the document first (and regardless of the wmode parameter of Flash)
4. I embed the VLC plugin and display a Flash animation as the source of an IFRAME. -> Whichever element is displayed last is in front of the other, regardless of zIndexes (no wmode parameter choice possible in this option, since src=foo.swf doesn't allow wmode setting)
5. I embed the VLC plugin and display an image as the source of an IFRAME. -> Whichever element is displayed last is in front of the other, regardless of zIndexes
6. I display a Flash animation as the source of an IFRAME and an image in an IFRAME. -> Whichever element is displayed last is in front of the other, regardless of zIndexes (no wmode parameter choice possible in this option, since src=foo.swf doesn't allow wmode setting)

The following combinations work, but there is no way of getting the VLC plugin to play nice with images and Flash:
7. I embed a Flash animation and display an image as the source of an IFRAME. -> OK
8. I embed a Flash animation and display an image in a DIV. -> OK
9. Displaying images in DIVs and/or IFRAMEs (no Flash, no VLC) -> OK

All above combinations work in Firefox 2, as long as I specify the "position: fixed" style for the DIVs and EMBEDs. Using fixed, absolute or relative position styles no longer change anything, and no longer work.
Seeing how the plugin is sometimes hidden, sometimes in front, depending on the way it is added, and the version of Firefox, I think the problem is related to Firefox, not the plugins themselves.

Methodology:
I say embed a plugin when I use the "embed" and "object" syntax, wrapped in a DIV. The DIV and the EMBED are the elements which have their z-index set (I also started by trying with only the DIV zIndex)
When I use an IFRAME, I simply do myIframe.src=foo.swf for instance, and put the IFRAME in a DIV. The DIV and the IFRAME are the elements which have their zIndex set
All my elements are dynamically added to the document using Javascript. Firebug confirms they all have expected styles set, only visually is there a problem.

This is confirmed on Firefox 3.0.5/Ubuntu 8.10 ; Firefox 3.1b2 / Linux ; and partially Firefox 3 on Win XP (same results for Flash and image interactions, no tests using VLC plugin as it wasn't available).

Reproducible: Always

Steps to Reproduce:
1. Choose one of the scenarios above
2. Configure Javascript code for selected scenario
3. Observe
edit the video_url and flash_url at the top of the file as needed
edit the z value in f1,f2,f3, or f4 as needed
edit the timeouts called in the main function: "mafct()" as needed

Thanks!
The z-index works only if the plugin is set into a windowless mode.
( https://developer.mozilla.org/En/Gecko_Plugin_API_Reference/Drawing_and_Event_Handling)
You set the mode for the flash plugin with the wmode=transparent/opaque.
Note: only flash10 supports the windowless mode on X11, not v9

>(no wmode parameter choice possible in this
>option, since src=foo.swf doesn't allow wmode setting)
without wmode setting the flash plugin is in the windowed mode and paints itself in the part of the window. A z-Index can not work in this case !

I don't think that the vlc plugin supports the windowless mode at all and you test confirms that.

I don't see anything that would be a bug in FF, marking invalid.
Please reopen if you have a case that isn't covered
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Please reopen this.

It turns out that FF on Linux/Mac will in fact allow an iframe to float in front of a Flash program (even with the default Flash wmode=transparent) but FF/Windows will not so that is inconsistent.

Further, you should reconsider making the FF Linux approach standard (that a windowed program like Flash CAN participate in layers) because such layers are used by many sites and allowing this is standard in IE, Chrome, Safari (and FF on Linux) so there is no point fighting that trend
Flags: blocking-firefox3.1?
Re-opening as per comment 3.

Either way this goes, this doesn't block, IMO. Tossing it over to Roc for triage as it feels like Layout, but also cc'ing Vlad and jst just in case!
Status: RESOLVED → UNCONFIRMED
Component: General → Layout
Flags: blocking-firefox3.1?
Product: Firefox → Core
QA Contact: general → layout
Resolution: INVALID → ---
The position:fixed workaround doesn't work anymore, but overflow:auto does.

I'm not sure why Windows and Linux are behaving differently here. Mac is completely different because it basically always uses windowless mode, which should always work correctly on all three platforms.

The core issues here --- windowed plugins not obeying z-index on Linux and Windows --- are to be addressed by compositor.
Blocks: 942972

We're in the process of removing support for plugins (bug 1677160) and bug 1687239 has removed the relevant Layout code, so this bug is irrelevant now.

Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: