Bug 44850 – swf files are downloaded when flash is disabled on www.grantgalitz.org

• Component: Plug-ins
• Status: RESOLVED WONTFIX

Go to any page with flash with a Chromium build that pulls in Webkit 66156, ie any build after Chromium-57724, and when flash is disabled, Chromium will automatically download the swf file.  I first found this bug on Chromium for FreeBSD 7.0.509-57790 and confirmed on the Win XP Chromium snapshots up to 57726.  Chromium 57723 doesn't have the bug, as it is before the Webkit roll at 57724.  I then compiled Chromium 57724 with a handful of Webkit commits between 66141 and 66191 and narrowed it down to 66156 (as 66155 doesn't show the bug, while 66156 does).  I was unable to confirm with the Webkit nightlies as the last 5-10 Webkit nightlies crash on Windows 7 and XP after the home page is loaded.

Someone else has confirmed this bug on Chromium for Windows 7, but he notes that it's not reproducible on all flash sites.  I notice now that I only had the problem on sites with youtube videos embedded, so perhaps it's an incompatibility between WebCore trunk and the youtube embedded flash player.

[Andy Estes]

I can reproduce this in a WebKit nightly build on the Mac. Here is the snippet the site uses to embed the flash video:

<object width="425" height="350">
    <param name="movie" value="http://www.youtube.com/v/6SDf5_Thqsk"></param>
    <param name="wmode" value="transparent"></param>
    <embed src="http://www.youtube.com/v/6SDf5_Thqsk" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed>
</object>

It probably has to do with there being no mime type specified on the <object>. The same thing happens in builds prior to r66156 if the type @attr is removed from the <embed>. When flash is enabled, it looks like the mime type is determined from the Content-Type header for the resource and the right plug-in is loaded, but I guess when the plug-in is disabled and no type is explicitly specified, WebKit doesn't know what to do and just downloads the file.

[Bernhard Bauer]

Created attachment 66654 [details]
Return ObjectContentNone for an empty <object> MIME type

If we return ObjectContentNone when the MIME type is empty, we don't start a URL request, so we don't end up downloading the file if we can't handle the MIME type.

[Andy Estes]

(In reply to comment #3)
> Created an attachment (id=66654) [details]
> Return ObjectContentNone for an empty <object> MIME type
> 
> If we return ObjectContentNone when the MIME type is empty, we don't start a URL request, so we don't end up downloading the file if we can't handle the MIME type.

It looks like this patch only fixes the issue for the chromium port. I verified this happens in Safari on the Mac, so it would be nice to fix this for all platforms.

Also, it seems like this patch would break the ability to use the object element to load resources in a subframe. Since it might not be possible to determine a resource's MIME type a priori (e.g. type @attr or filename extension), our current behavior is to load the resource in a subframe and determine the type from the HTTP Content-Type header. Doesn't this change that behavior?

[Andy Estes]

The patch posted to https://bugs.webkit.org/show_bug.cgi?id=45364 appears to fix this issue, at least in the case of youtube's embedded player.

While this appears to fix the problem in the latest Webkit nightly for Win XP, I updated to Chromium 7.0.522-59192 on FreeBSD, that uses Webkit commit 67178, and the problem is still there.  I confirmed with the 59192 Chromium build for Win XP that Chromium still has this problem, looks like there's still some interaction with Chromium-specific source that causes this problem to persist.

[Andy Estes]

(In reply to comment #6)
> While this appears to fix the problem in the latest Webkit nightly for Win XP, I updated to Chromium 7.0.522-59192 on FreeBSD, that uses Webkit commit 67178, and the problem is still there.  I confirmed with the 59192 Chromium build for Win XP that Chromium still has this problem, looks like there's still some interaction with Chromium-specific source that causes this problem to persist.

Chromium didn't merge this change due to a performance regression. See <https://bugs.webkit.org/show_bug.cgi?id=45524>.

This bug appears to be fixed in WebKit trunk with the original reason.tv url, but there are still other sites where the bug persists.  For example, the grantgalitz.org site linked above, which also uses the youtube embedded player.  I ran into the problem with Chromium for FreeBSD using WebKit commit 68248 and confirmed with the last WebKit nightly for Win XP, that uses commit 67637.

I don't know how to add a new url to the list of URLs above, so here's the URL:

http://www.grantgalitz.org/index.php

[Adam Barth]

Comment on attachment 66654 [details]
Return ObjectContentNone for an empty <object> MIME type

We need a test.

[Andy Estes]

Created attachment 70570 [details]
Test Case

[Andy Estes]

(In reply to comment #11)
> Created an attachment (id=70570) [details]
> Test Ccase

The embed in the test case has no type attribute, so we load the resource in a nested browsing context, which triggers a download since no plug-in exists that can handle the file type. I'm not sure if embeds should be able to load subframes like objects can. The spec only mentions nested browsing contexts in relation to the object element.

[Andy Estes]

(In reply to comment #9)
> I don't know how to add a new url to the list of URLs above, so here's the URL:
> 
> http://www.grantgalitz.org/index.php

It's worth noting that, in this case, WebKit's behavior is not a regression due to any recent changes to object/embed behavior. While this page does embed a youtube video, it doesn't actually use the embed markup advertised by youtube, so this isn't an issue that exists with embedded youtube videos in general.

I'll change the title to reflect that this issue isn't a regression.

[Andy Estes]

(In reply to comment #13)
> (In reply to comment #9)
> > I don't know how to add a new url to the list of URLs above, so here's the URL:
> > 
> > http://www.grantgalitz.org/index.php
> 
> It's worth noting that, in this case, WebKit's behavior is not a regression due to any recent changes to object/embed behavior. While this page does embed a youtube video, it doesn't actually use the embed markup advertised by youtube, so this isn't an issue that exists with embedded youtube videos in general.
> 
> I'll change the title to reflect that this issue isn't a regression.

I neglected to mention that I can reproduce this bug in Safari 5.0.2, hence my claim that this isn't a regression due to recent object/embed changes.

[Andy Estes]

<rdar://problem/9494958>

[Alexey Proskuryakov]

Mass closing plug-in bugs, as plug-in support has been removed from WebKit.

Please comment and/or reopen if this still affects WebKit in some way.