This will probably fix it but it'd be nice to have a test. I'll write one next.
Is NPPVpluginWantsAllNetworkStreams documented anywhere?
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.
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".
(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.
pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/90ab2594811b
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
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.
no chance for 5. release team would consider a patch for 6.
Comment on attachment 536728 [details] [diff] [review] fix v2.0 This patch works on mozilla-aurora. Requesting approval.
Attachment #536728 - Flags: approval-mozilla-aurora?
Do we know which plugins this affects? Are we blocklisting some plugins because of this?
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.
Josh, do we have any idea how popular this API is? I'm leaning towards saying we wait for the next uplift.
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.
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.
Attachment #536728 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Built locally and passed mochitest 'dom/plugins' (include new testcase). Pushed to mozilla-aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/0e97d6206a1e
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".
You need to log in before you can comment on or make changes to this bug.