Closed Bug 656448 Opened 14 years ago Closed 4 years ago

Rendering of youtube (or flash) iframe in foreignObject in inline SVG fails

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: pogon, Unassigned)

References

(
URL
)

Details

(Whiteboard: [platform-rel-Youtube])

Attachments

(3 files, 2 obsolete files)

testcase 2 (embedding flash in SVG [in html])
404 bytes, text/html
Details
reference case 2 (embedding flash in XHTML)
218 bytes, application/xhtml+xml
Details
testcase 3 (successfully renders flash in HTML, in an iframe within SVG foreignObject)
424 bytes, text/html
Details
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.65 Safari/534.24 Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 I see only a black rectangle where the video should appear. It works fine with the same SVG as standalone document. Reproducible: Always
OS: Linux → All
Hardware: x86_64 → All
Attached image testcase 1 (obsolete) —
Looks like we just aren't displaying flash at all, inside of SVG foreignObject. (including in iframes inside of foreignObject) Here's a testcase with two pieces of embedded content: (a) an <iframe> with Adobe's "find flash version" page. In the testcase, this has a big blank area where it should show you your flashplayer version. (below the text "The following displays the type of Flash Player version") (b) an <embed> with a SWF file from homestarrunner.com -- when I stick this embed in an HTML file, it works fine, but it's blank inside of <foreignObject>.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Attached file reference case 1 (using XHTML) (obsolete) —
In this reference case, I've merely replaced the "<svg...><foreignObject>" wrapper with <html>. This makes both the iframe and the <embed> display their flash contents.
(In reply to comment #0) > It works fine with the same SVG as standalone document. It's broken for me, in SVG as a standalone document. Do you see the flash contents in my testcase? (I don't.) If you have a standalone SVG file that correctly renders flash inside of <foreignObject>, could you attach it? Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110511 Firefox/6.0a1
You are right, I was wrong to say that it works with standalone SVG.
Isn't this just a duplicate of bug 477177? In particular, does using a windowless plug-in (which is NOT what youtube does) work?
platform-rel: --- → ?
Whiteboard: [platform-rel-Youtube]
platform-rel: ? → ---
The original testcase/reference-case are no longer effective, because (a) the adobe-hosted resource that they pointed to seems to have moved, and (b) we block the load of the HTTP (non-secure) homestarrunner resource that they pointed to (because bugzilla's attachments are served as HTTPS). Here's a fixed testcase that points to a different SWF test resource which is available over HTTPS: https://helpx.adobe.com/content/dam/help/en/flash-player/assets/flash_tree.swf This still reproduces the bug -- the resource fails to render in SVG, but it renders nicely in XHTML. (I'm also changing this SVG to be inline-svg-within-html so that bugzilla doesn't mistakenly show the SVG as a lightbox image, which would make the load fail for other reasons.)
Summary: Rendering of youtube iframe in foreignObject in inline SVG fails → Rendering of youtube (or flash) iframe in foreignObject in inline SVG fails
Just now seeing this comment: (In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #5) > Isn't this just a duplicate of bug 477177? Probably yes -- at least, both bugs are about plugins not rendering stuff inside of SVG foreignObject. > In particular, does using a windowless plug-in (which is NOT what youtube > does) work? (I don't know, & I'm not sure how to test this offhand. But it sounds like this was originally filed about a windowed plugin (2011-era youtube), which is a case that *is* covered by bug 477177.) So I'll just mark this as a dupe.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
If the problem is still reproducible today, then it's somewhat unlikely that this is a windowed plugin issue; I thought we no longer supported windowed mode. But maybe I'm misremembering?
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #9) > If the problem is still reproducible today It is; see testcase 2 vs. reference case 2 > then it's somewhat unlikely that > this is a windowed plugin issue; I thought we no longer supported windowed > mode. But maybe I'm misremembering? Hmm, OK. I'll un-dupe then. Is there an easy way to tell whether the flash_tree.swf link (in comment 6) is exercising windowed vs. windowless plugin mode? That's the flash content that I'm using in my newer testcase here.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I'm not sure offhand, but Benjamin may know how to check.
Flags: needinfo?(benjamin)
For comparison, here's some SVG with an <iframe> that contains (and does render) some flash content (the intro animation with a bouncing flash logo, and the "Version information" box on the right). This particular testcase started working as of bug 776054. (determined using mozregression --find-fix)
We have not successfully gotten rid of windowed-mode Flash all the way. On Windows, we should have windowless always on nightly/aurora and not on beta/release (tied to async rendering). On Mac, it's been windowless "forever". And on Linux we still do windowed. The testcases here WFM on windows/nightly.
Flags: needinfo?(benjamin)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #13) > The testcases here WFM on windows/nightly. Oh, interesting! (Note "testcase 2" is the only relevant thing that actually tests the bug right now.) Based on brief BrowserStack testing, I'm seeing that testcase 2 is broken in Firefox 50 release but WFM in Firefox 52 Aurora, on Windows 10. So maybe something became fixed here recently.
Attachment #531757 - Attachment is obsolete: true
Attachment #531758 - Attachment is obsolete: true
On native Windows 10 on my laptop, I'm seeing testcase 2 working just fine in 50.1.0. mozregression says it's been fine ever since bug 1276020's patch landed. (In recent builds before that point, the plugin wouldn't paint until I alt-tabbed or did something else to force a repaint.) So this is WFM on Windows 10, but something's still making testcase 2 fail to paint on Linux. (Possibly related to the fact that Linux is stuck on ancient flash versions -- though reference case 2 does work just fine there.)
Presumably if you add wmode="opaque" it would work everywhere, since Linux will still be trying to use native widgets. And that's expected.

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: REOPENED → RESOLVED
Closed: 8 years ago → 4 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: