Closed Bug 334321 Opened 14 years ago Closed 3 years ago

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

Categories

(Core :: Plug-ins, defect)

All
macOS
defect
Not set

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: jens, Unassigned)

References

()

Details

Attachments

(2 files)

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
This appears to WFM with Camino 1.0 en.  Can you attach a small screenshot?
(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.
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.
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?
Summary: Camino 1.0Int layer problem with guildwars.com → Background Flash object "image" appears on top of content at Guildwars.com; OK in Firefox
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.
*** Bug 334096 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have this same problem with Firefox 2.0.0.1 on OS X 10.4.8 with Flash player 9.0 r28.  
As an interesting additional note, it turns out that I also have this problem with Safari.  
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.
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.
Moving this to Core, as I see the same issues with Minefield builds as with Camino trunk builds.
Component: Page Layout → Plug-ins
Product: Camino → Core
QA Contact: page.layout → plugins
Version: unspecified → Trunk
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.  
Summary: Background Flash object "image" appears on top of content at Guildwars.com; OK in Firefox → Background Flash object "image" appears on top of content at Guildwars.com
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.
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
Flags: blocking1.9?
(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).
> 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.
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.
Assignee: nobody → joshmoz
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Duplicate of this bug: 416412
Duplicate of this bug: 410614
Duplicate of this bug: 419373
Attached file testcase
Testcase from dupe bug #419373 (Flash content renders over other content on Google Maps Street View).
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.
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).
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.
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.
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.
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?
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.
Duplicate of this bug: 448278
Summary: Background Flash object "image" appears on top of content at Guildwars.com → Flash sometimes draws on top of content in higher layers
Note:  Bug 448278 has significant additional information.
Summary: Flash sometimes draws on top of content in higher layers → Flash sometimes draws (floats) on top of content in higher layers
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.
Hardware: Macintosh → All
Bug 457384 may be yet another duplicate.
Bug 470012 is also possibly related or a dup.
Assignee: joshmoz → nobody
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.