334321 - Flash sometimes draws (floats) on top of content in higher layers

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Jens Habermann]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0 (MultiLang)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0 (MultiLang)

In Camino 1.0int the background layers of GuildWars.com are overlapping foreground content. This error didn´t occur in Firefox 1.502. 

Reproducible: Always

Steps to Reproduce:
1.goto www.guildwars.com
2.goto gallery
3.

Actual Results:  
The backgroung layer overlapping forground and colour errors appear

Expected Results:  
Layer should only display in background, like in Firefox

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This appears to WFM with Camino 1.0 en.  Can you attach a small screenshot?

Comment 2

[Jens Habermann]

(In reply to comment #1)
> This appears to WFM with Camino 1.0 en.  Can you attach a small screenshot?
> 

Here is a screenshot:
http://img525.imageshack.us/my.php?image=gw8jm.jpg
As you can see, the mesmer layer is front most and overlapping the content.

Comment 3

[philippe (part-time)]

I see those problems as well (Camino trunk build, 10.4.6).
All those 'backgrounds', the main horizontal navigation and the logo are all Flash objects with wmode set to transparent (and that is the key, I think).

I loaded the page in the screenshot (http://www.guildwars.com/gallery/), which loaded incorrectly (the pic of the man on the right covering the content), switched to another tab, then came back: the page displayed correctly. But let the mouse hover over that image and it jumps back on top. Hide Camino and  call it back, or switch tab and all is ok...

No problems in Firefox trunk. I suspect that if all Cocoa Widgets were implemented in Firefox, you'd see the same problems.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

So this is some sort of opacity/AppKit vs Gecko issue, a la bug 166932 or bug 187435?  Ooh, or bug 334096, too, perhaps?

(I see this now with philippe's tip; I just didn't have the patience before to stare at that page and wait to let it load in the front tab....)

Can someone with a cocoafox see if it happens in it, too?

Comment 5

[Simon Fraser [no longer active]]

This is because plugins are drawing outside of the NSView system; they just draw into the GrafPort of the WindowRef. I don't believe we have a good plugin layering story on any platform (particularly with accelerated drawing), but to fix it on Mac, plugins would have to use Quartz and do all their drawing in CGContexts.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 334096 has been marked as a duplicate of this bug. ***

Comment 7

[Deb Richardson [:dria] (plz NEEDINFO)]

I have this same problem with Firefox 2.0.0.1 on OS X 10.4.8 with Flash player 9.0 r28.  

Comment 8

[Deb Richardson [:dria] (plz NEEDINFO)]

As an interesting additional note, it turns out that I also have this problem with Safari.  

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm seeing this in Firefox 2.0.0.2pre and 3.0a2pre, with Flash Plugin 9.0 r20. It's inconsistent, almost as if it depends when the flash layer decides to draw.

Comment 10

[u59231]

Attachment: "The Scribe" on GuildWars.com.

The Warrior should be underneath the text.  I think that the image is a Flash object...  Oddly enough, I'm getting the same error with Firefox 2.x and Safari.  It could be a Flash problem.

Comment 11

[philippe (part-time)]

Moving this to Core, as I see the same issues with Minefield builds as with Camino trunk builds.

Comment 12

[Deb Richardson [:dria] (plz NEEDINFO)]

Consistently having this problem with Fx3 nightlies.  It's also appearing on another NCSoft site for the DungeonRunner game which I'm currently playing.  

http://www.dungeonrunners.com/

It no longer appears to be a problem on Safari (3.0.3), which I'm now having to use on affected sites.  

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Does updating the Flash plugin help? If it's working on Safari 3.0.3, that implies (to me) that it's more our problem than Flash's.

Comment 14

[Deb Richardson [:dria] (plz NEEDINFO)]

Updated to Flash 9r47 (from 9r28 -- I wasn't that far out of date). 

Intel Mac OSX 10.4.10 w/ Flash 9r47:
* Broken in Minefield (nightly)  
* Broken in Fx2.0.0.6
* Broken in Fx1.5.0.12 and 1.5.0.9
* Broken in Flock
* Broken in Camino
* Works fine in Safari
* Works fine in Opera
* Works fine in Vienna (rss reader)

Windows XP Pro w/ Flash9r45:
* Works in Minefield (nightly)
* Works in Fx2.0.0.6
* Works in IE7
* Works in Flock

Comment 15

[Colin Barrett [:cbarrett]]

(In reply to comment #14)
> Updated to Flash 9r47 (from 9r28 -- I wasn't that far out of date). 
>
> * Works fine in Safari

Tested it in Safari 2 (since you said you were using 3), works there (using the http://www.dungeonrunners.com/ URL deb pasted).

Josh, do you have any idea? I don't know how plugin paint events are fired in Cocoa Widgets. Could be any number of problems (bad ordering of paint events, giving the plugin bad rects to paint in, the plugin just drawing wherever it wants, etc).

Comment 16

[Simon Fraser [no longer active]]

> the plugin just drawing wherever it wants

I think there's an implicit agreement (for most plugins, anyway) that they only draw when we send them events, including the periodic null events. Plugins that used accelerated drawing, like Director, QuickTime and anything OpenGL based, can draw at any time, and will probably not composite with other content.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Since this is not a regression it's not a blocker. That said, it would be great to have it fixed, so marking wanted.

Josh, this looks mac specific. If you have spare cycles, feel free to have a look and see if it's something we can fix.

Comment 23

[Matthew Gregan [:kinetik]]

Attachment: testcase

Testcase from dupe bug #419373 (Flash content renders over other content on Google Maps Street View).

Comment 24

[Matthew Gregan [:kinetik]]

Also worth noting that this might not show up as often on trunk, because we have support for CoreGraphics plugin drawing (since bug #344427 landed) and Flash >= r60 supports the CoreGraphics plugin drawing model.

Comment 25

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Given comment 5 and the fact that you'd have to be 4 or more security releases of the Flash plug-in (and 9 months) out-of-date, is there any reason not to just close this FIXED by bug 344427 and a current Flash plug-in)?

Both comment 10 and comment 32 work fine for me on current trunk and current Flash plug-in (9.0 r115).

Comment 26

[philippe (part-time)]

That layering issue at the root of this bug seems to be gone, at least on Intel +10.5.2 + flash 9.0r115.
However, there are still positioning differences with Safari, both with the testcase in comment 23 and the 'Scribe' from the URL (http://www.guildwars.com/community/default.php) - I think Safari does what the page authors intended: Scribe to the right of the page (that could be a separate bug, though.

Also, how does this work on PPC machines (10.4 or 10.5)? One of the duped bugs (bug 410614) could not be reproduced on Intel 10.5 - I could see it on 10.4 ppc.

Comment 27

[Matthew Gregan [:kinetik]]

It's not positioning in my testcase, it's that Safari and Minefield are rendering the Flash content at a different size (the embed doesn't specify a size in the testcase, if I change it so it does, both render it the same way).  I don't know if it's a bug that the size is different in this case.  If anything, I think Minefield is getting it right, since (as far as I can tell), the Flash content wants to be 240x200 and that's how Minefield is sizing it.

It does look like something weird is going on with the Guild Wars site, since the Flash logo does have a size specified, both browsers render it at the correct size, but it's positioning incorrectly (according to the site design) in Minefield.  This seems like a bug, it needs more investigation, but whatever is going on it's separate from this bug.

Comment 28

[philippe (part-time)]

Yeah, in the test case, it is just a difference on how the intrinsic size of the Flash object is understood: Safari: 300px by 150px, Gecko: 200 by 240px. WebKit follows quite close what the CSS 2.1:10 assumes for intrinsic size.

On the Guild Wars page, it is a <table> issue, the (2 column) table should be as wide as the page, but for some reason it collapses, with the left column having a computed width of 0. It possibly is a very old bug, I need more testing to be certain.

Comment 29

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

In any case, if there are issues with size and/or positioning, please file a separate bug for that issue.

Sounds like this bug is fixed with the latest release of flash? Can we mark this WORKSFORME then?

Comment 30

[philippe (part-time)]

I figured out the positioning issue on the Guild Wars site. Gecko 1.9 is correct, WebKit is wrong.
The table that contains the scribe (Flash Object) is wrapped in an _absolute positioned_ <div>. That <div> has no width specified, and collapses to the width of the Flash Object.
Opera 9.5b does the same as Gecko.

(In reply to comment #29)
The only question open (from my comment 26):

> Also, how does this work on PPC machines (10.4 or 10.5)? One of the duped bugs
> (bug 410614) could not be reproduced on Intel 10.5 - I could see it on 10.4
> ppc.
> 

I don't have access to a PPC machine to test.

Comment 34

[Steven Michaud [:smichaud] (Retired)]

Note:  Bug 448278 has significant additional information.

Comment 35

[Asaf Romano (gone)]

Attachment: storm.php

Comment 36

[Chris Lawson (gone)]

Comment 14 suggests this particular bug isn't a problem on Windows.

Comment 5, however, suggests that it certainly *could* be.

Is there a Windows version of this bug? (This one is obviously not Intel- or PPC-specific.)

It looks to me like bug 253474 is another instance of it, but someone more knowledgeable than I should really take a look over there and see.

Comment 37

[Zack Weinberg (:zwol)]

Bug 457384 may be yet another duplicate.

Comment 38

[Steven Michaud [:smichaud] (Retired)]

Bug 470012 is also possibly related or a dup.