Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 660989 - NPAPI OOP Plugin System does not transmit NPPVpluginWantsAllNetworkStreams
: NPAPI OOP Plugin System does not transmit NPPVpluginWantsAllNetworkStreams
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: All All
: -- major (vote)
: ---
Assigned To: Josh Aas
: Benjamin Smedberg [:bsmedberg]
Depends on:
  Show dependency treegraph
Reported: 2011-05-31 14:47 PDT by Thomas Harning
Modified: 2013-12-27 14:20 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

fix v1.0 (4.34 KB, patch)
2011-06-01 10:31 PDT, Josh Aas
no flags Details | Diff | Splinter Review
fix v2.0 (18.14 KB, patch)
2011-06-01 13:52 PDT, Josh Aas
benjamin: review+
asa: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Thomas Harning 2011-05-31 14:47:20 PDT
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.68 Safari/534.30
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

NPPVpluginWantsAllNetworkStreams is a required item for our plugin in dealing with web service request errors since they return 500 status codes.

Visible in dom/plugins/PluginInstanceChild.cpp and dom/plugins/PluginInstanceParent.cpp is a lack of handling for this value.  The utilities parse it out and I can find log statements when running with NSPR_LOG_MODULE=all:5 that value 18 (NPPVpluginWantsAllNetworkStreams) is not handled for both NPN_SetValue and NPP_GetValue calls.

If I manually disable OOPP, the plugin works correctly.

Reproducible: Always

Steps to Reproduce:
1. Setup an NPAPI plugin that handled NPP_GetValue return returns 'true' for NPPVpluginWantsAllNetworkStreams in the correct manner (or sets it using NPN_SetValue)
2. Ensure OOPP is enabled for the NPAPI plugin in question
3. Perform a web request known to return a non-200 result with NPP_GetURLNotify or NPP_PostURLNotify

Actual Results:  
1) No callback to NPP_GetValue for NPPVpluginWantsAllNetworkStreams.
2) A URLNotify callback with failure and no additional data

Expected Results:  
1) A callback to NPP_GetValue for NPPVpluginWantsAllNetworkStreams of not set already.
2) A full web request response with headers and data

Since this issue can be resolved by blacklisting the plugin in the configuration. 

I 'can' work around this issue by setting the global MOZ_DISABLE_OOP_PLUGINS=1 or using global javascript configuration file (will need to figure out how)... however this is not desirable.

This bug strongly affects software that we are trying to deploy.
Comment 1 Josh Aas 2011-06-01 10:31:38 PDT
Created attachment 536655 [details] [diff] [review]
fix v1.0

This will probably fix it but it'd be nice to have a test. I'll write one next.
Comment 2 Benjamin Smedberg [:bsmedberg] 2011-06-01 10:47:49 PDT
Is NPPVpluginWantsAllNetworkStreams documented anywhere?
Comment 3 Josh Aas 2011-06-01 10:58:14 PDT
Actually, that patch may not do anything. It looks like we query the plugin for the value when we need it and don't support having the plugin set it on the browser.
Comment 4 Josh Aas 2011-06-01 11:05:06 PDT
We also don't seem to be consistent about when we request that information from the plugin. For byte range streams we check when "responseCode != 200", for other streams we do it when "responseCode > 206".
Comment 5 Thomas Harning 2011-06-01 11:11:01 PDT
(In reply to comment #2)
> Is NPPVpluginWantsAllNetworkStreams documented anywhere?
It is documented in the source code as a value to denote that the plugin wants all network streams, including error cases instead of throwing a network error to the plugin.

In my experience, Firefox has performed a NP_GetValue on this prior to either returning a network error or giving back all web request data (based on true/false value).  It also looks like NP_SetValue 'should' work, but I have not used it except when trying to debug this problem.
Comment 6 Josh Aas 2011-06-01 13:52:54 PDT
Created attachment 536728 [details] [diff] [review]
fix v2.0
Comment 7 Josh Aas 2011-06-08 13:23:07 PDT
pushed to mozilla-central
Comment 8 Josh Aas 2011-06-08 13:26:10 PDT
This is a safe regression fix with a test. I think we should consider porting to Aurora (FF6). I'll write the patch if there is an indication that we'd take it.
Comment 9 Asa Dotzler [:asa] 2011-06-09 14:23:45 PDT
no chance for 5. release team would consider a patch for 6.
Comment 10 Josh Aas 2011-06-09 15:47:34 PDT
Comment on attachment 536728 [details] [diff] [review]
fix v2.0

This patch works on mozilla-aurora. Requesting approval.
Comment 11 [:Cww] 2011-06-16 14:55:53 PDT
Do we know which plugins this affects? Are we blocklisting some plugins because of this?
Comment 12 Thomas Harning 2011-06-19 12:03:50 PDT
It affects a plugin for a product that is in the progress of being released.  I do not know if I can name it, if we can get put on a blacklist for 4.0 quickly, I could probably convince management to release the information to get put on the blacklist.  We are supporting Firefox 3.6 and 4.0 at the moment, of which 3.6 doesn't have a problem unless users alter the Mozilla configurations.

To workaround the issue, we are deploying a Firefox Extension registered using the HKLM\Software\Mozilla\Firefox\Extensions registry area to inject a preferences setting that blacklists our plugin DLL from OOP execution.  While this is a working fix, it is somewhat "unsightly" from the user-experience side with the user seeing a pop-up that an extension was just installed.
Comment 13 Asa Dotzler [:asa] 2011-06-23 15:02:54 PDT
Josh, do we have any idea how popular this API is? I'm leaning towards saying we wait for the next uplift.
Comment 14 Josh Aas 2011-06-23 15:10:34 PDT
I don't remember exactly who uses it but it's probably popular enough that not supporting it worries me. Given how simple this patch is and how this feature can make or break some significant plugin functionality I'm inclined to recommend that we push this to aurora.
Comment 15 Asa Dotzler [:asa] 2011-06-23 15:30:08 PDT
OK, I'm leaning back in the other direction now. Thanks Josh. Any other drivers, if you'll second this, go ahead and mark it. If no one gets to this before Tuesday, we'll get it in that triage meeting.
Comment 16 Benoit Girard (:BenWa) 2011-06-29 10:22:31 PDT
Built locally and passed mochitest 'dom/plugins' (include new testcase).

Pushed to mozilla-aurora:
Comment 17 Thomas Harning 2011-06-29 11:38:18 PDT
Reporting that I have found the issue as fixed in the nightly builds without the workaround that puts our extension in the set of "blacklisted from out-of-process plugins".

Note You need to log in before you can comment on or make changes to this bug.