Bug 25332 – Plug-in inserted in to DOM of PluginDocument fails to load

• Component: Plug-ins
• Status: RESOLVED FIXED

[Simone Manganelli]

When loading a bare .swf file in a WebKit window or tab, WebKit creates a skeleton DOM around the file before loading it.  This skeleton DOM works correctly when not intercepted by a plug-in.  When it's intercepted by a ClickToFlash plugin, however, which eventually releases the .swf file to the Flash plugin after clicking on it, the skeleton DOM ceases to allow the display of the .swf file.

The source for the latest code of ClickToFlash will demonstrate this problem: http://github.com/rentzsch/clicktoflash/tree/master .  From what I can tell, this is not a ClickToFlash problem, because a file with identical HTML will allow the .swf file to load, but the same exact HTML that's eventually loaded by WebKit after ClickToFlash causes the .swf file *not* to load.


Steps to Reproduce:

1.  Make sure the ClickToFlash plugin is not installed.

2.  Launch WebKit.

3.  Navigate to http://www.somethingawful.com/flash/shmorky/babby.swf .  Note that the .swf file loads and displays immediately.

4.  Install the ClickToFlash plugin.

5.  Navigate to http://www.somethingawful.com/flash/shmorky/babby.swf .  Note that ClickToFlash intercepts the .swf file and displays a ClickToFlash view.

6.  Click on the ClickToFlash view.  Note that ClickToFlash releases the .swf file to the Adobe Flash plugin, but displays nothing.

7.  Control-click on the Flash view.  Note that the contextual menu says "Movie not loaded...".

8.  Select [Develop --> Show Web Inspector].  Look at the HTML of the resultant skeleton DOM that WebKit creates around the .swf file.

9.  Open a new tab.  Navigate to http://homepage.mac.com/simx/test-ctf-flash.html .  Observe that ClickToFlash intercepts the .swf file and displays a ClickToFlash view.

10.  Click on the ClickToFlash view.  Note that ClickToFlash releases the .swf file to the Flash plugin, and this time, it displays *correctly*.

11.  Select [Develop --> Show Web Inspector].  Look at the HTML of the file.  Note that this HTML is *identical* to the HTML observed in step 8, but with different results!  The .swf file plays correctly when linked to from this HTML page, but when WebKit constructs the DOM after ClickToFlash releases the .swf file, WebKit refuses to play it.


Expected Results: I expect identical resultant HTML to result in identical display of the contents.


Actual Results: Identical HTML coming from different sources unexpectedly has different results.  If the HTML is from an HTML file, .swf files play fine.  If the same, identical HTML is constructed by WebKit when loading a bare .swf file after ClickToFlash interception, WebKit refuses to play the .swf file.

[Simone Manganelli]

Please note, this bug can be tracked on ClickToFlash's bug tracking system here: http://rentzsch.lighthouseapp.com/projects/24342/tickets/75-cant-play-local-content 

Also, I have tried to programatically construct an enclosure div and even a separate OBJECT tag to try and load the .swf files after ClickToFlash releases them, but to no avail.  Sample code:

id parent = self.container.parentNode;
[parent removeChild:self.container];
[self.container setAttribute:@"allowscriptaccess" value:@"always"];
DOMElement *newNode = [[self.container ownerDocument] createElement:@"div"];
DOMElement *cloneNode = (DOMElement *)[self.container cloneNode:YES];
DOMElement *objectNode = [[self.container ownerDocument] createElement:@"object"];
[objectNode setAttribute:@"type" value:@"application/futuresplash"];
[objectNode setAttribute:@"data" value:self.src];
DOMElement *paramNode = [[self.container ownerDocument] createElement:@"param"];
[paramNode setAttribute:@"name" value:@"movie"];
[paramNode setAttribute:@"value" value:self.src];
[parent appendChild:newNode];
[newNode appendChild:self.container];
[newNode appendChild:cloneNode];
[newNode appendChild:objectNode];
[objectNode appendChild];

[Mark Rowe (bdash)]

Full-frame plug-ins are handled via instances of the PluginDocument subclass of HTMLDocument, rather than HTMLDocument itself.  The standard HTML tokenizer is entirely bypassed and DOM is explicitly created.  This difference in implementation may be responsible for the difference in behavior.  It may be related to the fact that PluginTokenizer::writeRawData calls FrameLoaderClient::redirectDataToPlugin which seems like it may influence how data is loaded.

[Mark Rowe (bdash)]

<rdar://problem/6818421>

[Simone Manganelli]

Created attachment 29699 [details]
reduction of ClickToFlash plugin that loads Flash content and then immediately passes off to Flash plugin

[Mark Rowe (bdash)]

Created attachment 29969 [details]
Reduction that builds

[Mark Rowe (bdash)]

I spent a little while debugging this tonight.  What's happening is that when creating the Flash plug-in, WebFrameLoaderClient::createPlugin is being called with loadManually=true, indicating that the main resource stream should be used for the data.  However, this stream was already used for the WebKit plug-in that was initially created.  Since loadManually is not false we won't explicitly request the plug-in source URL, resulting in the Flash plug-in never receiving any data.  The code in FrameLoader::loadPlugin currently always sets loadManually=true for plug-ins in a plug-in document, working on the assumption that there will only ever be a single plug-in in the document.  ClickToFlash's behavior clearly violates this assumption.  We can fix this by having FrameLoader::loadPlugin only pass loadManually=true if the plug-in will receive data from the main resource.  I can't see a direct way of determining that, but we can approximate this by checking if this is the first plug-in to be inserted in to the plug-in document (isPluginDocument() && !m_containsPlugIns).  In my tests, this fixes the bug.

[Mark Rowe (bdash)]

Also, is it just me or is loadManually a rather confusing name for the parameter?  When it's set to false, we explicitly load the resource.  If it's true, then we don't load anything…

[Mark Rowe (bdash)]

Created attachment 29986 [details]
Patch

[Mark Rowe (bdash)]

Landed in r43181.

[Simone Manganelli]

Confirmed fixed.