Bug 60568 – REGRESSION (WebKit2): Flash plugin doesn't appear on a hanes.com page

• Component: Plug-ins
• Status: RESOLVED FIXED

[Adam Roben (:aroben)]

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..."

[Adam Roben (:aroben)]

<rdar://problem/8610657>

[Adam Roben (:aroben)]

The bug does not occur in WebKit1.

[Adam Roben (:aroben)]

Nor does it occur on Mac.

[Adam Roben (:aroben)]

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.

[Adam Roben (:aroben)]

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?

[Adam Roben (:aroben)]

I don't see any calls being made back into WebKit from within NPP_NewStream. Maybe some earlier call is to blame.

[Adam Roben (:aroben)]

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)

[Adam Roben (:aroben)]

I tried using the Flash content debugger plugin. The only output that's generated is:

Warning: Reference to undeclared variable, 'disableBlocker'

[Adam Roben (:aroben)]

It looks like WebKit2 calls NPP_URLNotify for the javascript: URLs the plugin loads, while WebKit1 does not. Maybe that's significant?

[Adam Roben (:aroben)]

I tried making WebKit2 never call NPP_URLNotify for javascript: URLs (just for testing purposes), and this bug went away.

[Adam Roben (:aroben)]

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".

[Adam Roben (:aroben)]

Relevant WebKit1 code: <http://trac.webkit.org/browser/trunk/Source/WebCore/plugins/PluginView.cpp?rev=84371#L474>

[Adam Roben (:aroben)]

In WebKit2, we are telling the plugin that the javascript: load failed (because the result of the script evaluation is a null string).

[Adam Roben (:aroben)]

Next I will try making WebKit2 always tell Flash that the javascript: load succeeded, to see whether that is sufficient to fix the bug.

[Alexey Proskuryakov]

I wonder if this is related to bug 36721 at all.

[Adam Roben (:aroben)]

(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.

[Adam Roben (:aroben)]

(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>

[Adam Roben (:aroben)]

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)

[Adam Roben (:aroben)]

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)

[Adam Roben (:aroben)]

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)

[Adam Roben (:aroben)]

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).

[Adam Roben (:aroben)]

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"

[Adam Roben (:aroben)]

(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

[Adam Roben (:aroben)]

(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.

[Adam Roben (:aroben)]

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.

[Adam Roben (:aroben)]

I confirmed that my analyses of the various implementations' behaviors were correct using a test page.

[Adam Roben (:aroben)]

Created attachment 93164 [details]
Don't notify the plugin when a targeted javascript: URL request completes

[Adam Roben (:aroben)]

Committed r86259: <http://trac.webkit.org/changeset/86259>