To reproduce: 1. Go to http://www.hanes.com/Hanes/Products/Kids-Hanes/Kids_Boys-Hanes/Kids_Boys_boysbottoms-Hanes/WD307.aspx The picture of the product never appears. If you right-click in the blank area, you see "Movie not loaded..."
<rdar://problem/8610657>
The bug does not occur in WebKit1.
Nor does it occur on Mac.
Things seem to proceed about the same in WebKit1 and WebKit2 until we're asked to load this URL: http://hanes.richfx.com.edgesuite.net/image/viewers/base/asp/getSettings.aspx?RFX_SettingsPath=settings/&RFX_Image=WD307_YT&RFX_DontCache=False&RFX_Client=hanes&RFX_Catalog=&RFX_Int=anyspot_hanes&RFX_Lang= When we call NPP_NewStream in WebKit2, we get back an NPERR_STREAM_NOT_SEEKABLE error. When we call NPP_NewStream in WebKit1, we get back NPERR_NO_ERROR.
Looks like WebKit1 and WebKit2 are passing the same parameters to NPP_NewStream. Maybe Flash is calling back into WebKit from inside NPP_NewStream and we're doing something different in WebKit1 vs. WebKit2?
I don't see any calls being made back into WebKit from within NPP_NewStream. Maybe some earlier call is to blame.
Here are the NPP_NewStream calls we make: NPP_NewStream("application/x-shockwave-flash", "http://hanes.richfx.com.edgesuite.net/image/viewers/base/loader.swf", false, NP_NORMAL) NPP_NewStream("application/x-shockwave-flash", "http://hanes.richfx.com.edgesuite.net/image/viewers/base/Zeus.swf", false, NP_NORMAL) NPP_NewStream("text/xml", "http://hanes.richfx.com.edgesuite.net/image/viewers/base/asp/getSettings.aspx?RFX_SettingsPath=settings/&RFX_Image=WD307_YT&RFX_DontCache=False&RFX_Client=hanes&RFX_Catalog=&RFX_Int=anyspot_hanes&RFX_Lang=", false, NP_NORMAL)
I tried using the Flash content debugger plugin. The only output that's generated is: Warning: Reference to undeclared variable, 'disableBlocker'
It looks like WebKit2 calls NPP_URLNotify for the javascript: URLs the plugin loads, while WebKit1 does not. Maybe that's significant?
I tried making WebKit2 never call NPP_URLNotify for javascript: URLs (just for testing purposes), and this bug went away.
WebKit1 doesn't call NPP_URLNotify for javascript: URLs if the URL had a non-null target. The javascript: URLs in question here (which all have the form "javascript:geturl_FSCommand('debug', ...)") all have a target of "_self".
Relevant WebKit1 code: <http://trac.webkit.org/browser/trunk/Source/WebCore/plugins/PluginView.cpp?rev=84371#L474>
In WebKit2, we are telling the plugin that the javascript: load failed (because the result of the script evaluation is a null string).
Next I will try making WebKit2 always tell Flash that the javascript: load succeeded, to see whether that is sufficient to fix the bug.
I wonder if this is related to bug 36721 at all.
(In reply to comment #14) > Next I will try making WebKit2 always tell Flash that the javascript: load succeeded, to see whether that is sufficient to fix the bug. That does seem to be sufficient.
(In reply to comment #12) > Relevant WebKit1 code: <http://trac.webkit.org/browser/trunk/Source/WebCore/plugins/PluginView.cpp?rev=84371#L474> More relevant code: WebKit1 Mac: <http://trac.webkit.org/browser/trunk/Source/WebKit/mac/Plugins/WebNetscapePluginView.mm?rev=85036#L1573> WebKit2: <http://trac.webkit.org/browser/trunk/Source/WebKit2/WebProcess/Plugins/PluginView.cpp?rev=85036#L753>
Here's a summary of the behaviors of the various plugin implementations, from reading the code. (I've omitted the cases where no notification was requested.): WebKit1 Mac: * If the target is null * If the result is non-empty * Send the result via a stream * NPP_URLNotify(NPRES_DONE) * Else * Do nothing * Else * NPP_URLNotify(NPRES_DONE) WebKit1 Windows (and Qt, GTK+, etc.): * If the target is null * Send the result via a stream * If the result is null * NPP_URLNotify(NPRES_NETWORK_ERR) * Else * NPP_URLNotify(NPRES_DONE) * Else Do nothing WebKit2: * If the target is null * Send the result via a stream * If the result is null * NPP_URLNotify(NPRES_NETWORK_ERR) * Else * NPP_URLNotify(NPRES_DONE) * Else * If the result is null * NPP_URLNotify(NPRES_NETWORK_ERR) * Else * NPP_URLNotify(NPRES_DONE)
Found another implementation (of course!): <http://trac.webkit.org/browser/trunk/Source/WebKit/mac/Plugins/Hosted/NetscapePluginInstanceProxy.mm?rev=83385#L688> WebKit1 Mac OOP: * If the target is null * Do nothing * Else if the result is empty * Do nothing * Else * Send the result via a stream * NPP_URLNotify(NPRES_DONE)
The requests that seem to matter on this page have the following attributes: 1) Target is not null ("_self") 2) Result is null Based on the above pseudocode, this means the implementations have the following behavior on this page: WebKit1 Mac: * NPP_URLNotify(NPRES_DONE) WebKit1 Mac OOP: * Do nothing WebKit1 Windows (/Qt/GTK/etc.): * Do nothing WebKit2: * NPP_URLNotify(NPRES_NETWORK_ERR)
Another implementation: http://google.com/codesearch/p#OAMlx_jo-ck/src/webkit/plugins/npapi/webplugin_impl.cc&l=1073 http://google.com/codesearch/p#OAMlx_jo-ck/src/webkit/plugins/npapi/plugin_instance.cc&l=360 http://google.com/codesearch/p#OAMlx_jo-ck/src/webkit/plugins/npapi/plugin_string_stream.cc&l=23 Chromium: * If the result is null * NPP_URLNotify(NPRES_DONE) * Else * Send the result via a stream * NPP_URLNotify(NPRES_DONE) I've only included the behavior for javascript: requests above. Note that the target is ignored (other than an initial security check).
And another: http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsNPAPIPlugin.cpp#975 http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginHost.cpp#642 http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#3402 http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginHost.cpp#3095 http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsNetUtil.h#212 http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsIOService.cpp#597 http://mxr.mozilla.org/mozilla-central/source/dom/src/jsurl/nsJSProtocolHandler.cpp#1252 http://mxr.mozilla.org/mozilla-central/source/dom/src/jsurl/nsJSProtocolHandler.cpp#636 http://mxr.mozilla.org/mozilla-central/source/dom/src/jsurl/nsJSProtocolHandler.cpp#748 http://mxr.mozilla.org/mozilla-central/source/dom/src/jsurl/nsJSProtocolHandler.cpp#170 http://mxr.mozilla.org/mozilla-central/source/dom/src/jsurl/nsJSProtocolHandler.cpp#862 Mozilla: * If the target is null * Send the result via a stream * If the result is null * NPP_URLNotify(NPRES_NETWORK_ERROR) * Else * NPP_URLNotify(NPRES_DONE) * Else * Do nothing So, for the javascript: requests relevant for this bug, Mozilla will "* Do nothing"
(In reply to comment #20) > Based on the above pseudocode, this means the implementations have the following behavior on this page: > > WebKit1 Mac: > * NPP_URLNotify(NPRES_DONE) > > WebKit1 Mac OOP: > * Do nothing > > WebKit1 Windows (/Qt/GTK/etc.): > * Do nothing > > WebKit2: > * NPP_URLNotify(NPRES_NETWORK_ERR) Chromium: * NPP_URLNotify(NPRES_DONE) Mozilla: * Do nothing
(In reply to comment #15) > I wonder if this is related to bug 36721 at all. Yes, it is related. But it's only dealing with non-javascript: requests.
Mozilla and WebKit1 Windows/Qt/GTK+/etc. have the same behavior with respect to javascript: requests. Anders and I think we should make WebKit2 have this same behavior.
I confirmed that my analyses of the various implementations' behaviors were correct using a test page.
Created attachment 93164 [details] Don't notify the plugin when a targeted javascript: URL request completes
Committed r86259: <http://trac.webkit.org/changeset/86259>