New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 332481 link

Starred by 28 users

Issue metadata

Status: Fixed
Closed: Jan 2014
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Requests from within Flash (NPAPI) aren't handled by chrome.webRequest.onBeforeRequest anymore

Reported by, Jan 8 2014

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Safari/537.36

Steps to reproduce the problem:
1. Go to chrome://plugins, expand Details, and make sure Adobe Flash Player (PPAPI) is disabled.
2. Install the extension from the attachment.
3. Go to, and play any video.
4. Inspect the background page of the extension and go to "Console".

What is the expected behavior?
The sample extension logs all web requests of the type "object". So I would expect to see all requests issued by the Flash video, like it does on Chrome <= 22 or when Flash (PPAPI) is enabled.

What went wrong?
Starting with Chrome 23, requests issued from NPAPI plugins aren't handled by chrome.webRequest.onBeforeRequest anymore.

WebStore page: 

Did this work before? Yes Chrome 22 and before

Chrome version: 32.0.1700.72  Channel: beta
OS Version: 
Flash Version: Shockwave Flash 12.0 r0

This breaks extensions like Adblock Plus, on sites that use Flash, if the user uses the NPAPI instead of the PPAPI Flash plugin.
857 bytes Download
I meant Chrome 32 instead of 23 and Chrome 31 instead of 22, above. Could somebody please fix that that in the issue description? Sorry.

Comment 2 by Deleted ...@, Jan 11 2014

Youtube and adblock plus does not work anymore. Just blackscreen and audio.

Comment 3 by, Jan 13 2014

I have the same experience as those above.

Comment 4 by, Jan 13 2014

Labels: Cr-Internals-Plugins-Flash Cr-Privacy Cr-Internals-Plugins
Status: Untriaged
ccing some folks.

Note, however, that NPAPI support on Linux is on it's way out, generally: Does this bug effect PPAPI plugins as well? From the description, it appears that it doesn't...

Does it effect platforms other than Linux?
Thank you, Mike. Yes, this affects all platforms - but only NPAPI plugins. It seems that current plan is to remove support for NPAPI in Chrome 34. While this means that the issue will resolve itself automatically, it will still significantly impact Adblock Plus functionality for two release cycles (three months at the very least). Other extensions using webRequest API like Ghostery will be affected as well.
This seems related to a problem which was reported by a user of my extension on "chromium 34.0.1788.0 (244965) windows xp service pack 3":

The plugin requests are still reported to chrome.webRequest.onBeforeRequest, but they reported as "tabless" requests, i.e. not originating from a particular tab. The challenge now is to find a way (if any) to figure from which tab these requests occurred.
From my understanding of how Adblock+ works, and how HTTPSB, both are affected because they fail to link the request to the tab from which it originate, details.tabId === -1. If there is a way to reliably associate the request to the proper tab from which it really originate, that would prevent both extensions (and who knows what else extensions) to not break.
Ugh... "that would prevent both extensions to not break" should be "that would allow both extensions to deal with the change without breaking (with soon to be released version of chromium)"

Comment 9 by Deleted ...@, Jan 16 2014

Is this bug also affecting Silverlight plugin?

Example: (Finnish site). Video ads are blocked in 31 but not in 32.

Google Chrome + ABP 1.7.2 + Windows 8.1.

15.3 KB View Download
11.1 KB View Download
> "Is this bug also affecting Silverlight plugin?"

Yes, for the same reason: calls to webRequest.onBeforeRequest() have details.tabId set to -1 instead of the id of the tab in which the plugin sits:

details.frameId: -1
details.method: "GET"
details.parentFrameId: -1
details.requestId: "3184"
details.tabId: -1 <<<<<<<<<<<<<<<<<<<<<<< the issue
details.timeStamp: 1389901564397.428
details.type: "object"
details.url: ""

maybe that's a side effect of one of the OOPI refactorings?

Comment 12 by, Jan 17 2014

Status: Started
@jochen: yep that's probably the cause because we switched to fetching plugin requests from the plugin process directly instead of going through the renderer.

Also able to reproduce this issue in Google Chrome 32.0.1700.76 running in Windows 7.

Comment 14 by, Jan 19 2014

Anthony: do we want to merge this to M33?
Project Member

Comment 15 by, Jan 19 2014

r245847 | | 2014-01-19T23:41:24.881389Z

Changed paths:

Fix chrome.webRequest.onBeforeRequest for requests coming from NPAPI plugin processes.

BUG= 332481

Review URL:
When can we expect an updated release of Chrome 32 with this bug fixed?

Comment 17 by, Jan 21 2014

Labels: M-33 Merge-Requested
Status: Fixed
This won't be merged into M32 since that release is already out and this bug is not serious enough to merge, given that it only affects NPAPI plugins.

Anthony: your call on M33. I'll mark Merge-Requested for you to see it.

Comment 18 by, Jan 21 2014

Labels: -Merge-Requested Merge-Approved
Let's verify it on Canary, but will add approval, assuming that the issue has been resolved.
I tested this on Mac OS X, with the NPAPI Flash plugin:

Chrome 32.0.1700.77: object requests are reported with tabId == -1.
Chrome 34.0.1798.0 canary: object requests are reported with a valid tabId value but with frameId == -1.

So right now this issue isn't completely fixed. However, not having a valid frame ID is a relatively minor issue that we can work around at least...
So, if this won't be merged in v32, when will we see a beta v33 with the fix included?

Thanks in advance.

Comment 21 by, Jan 22 2014

@trev: i'm hesitant to plumb frame id to the plugin code. this is a code path that will be removed in the near future when we remove support for NPAPI plugins.

It sounds like the tabId is enough for now.

Comment 22 by, Jan 22 2014

Labels: -OS-Linux -M-33 -Merge-Approved
I looked into merging this. It's not a straight forward merge because of other changes that have happened.

Given that this only affects NPAPI plugins, and this stuff works fine for pepper, I don't think this is that important to merge to M33. Almost all users are using pepepr flash.

Comment 23 by, Jan 27 2014

I disagree w/ "amost all users are using pepper flash":

The performance w/ Pepper flash is not as good....

Comment 24 Deleted

no, does not work fine with pepper. It needs to be merge to 33
> no, does not work fine with pepper.

Then you should file a new bug. This bug, and the corresponding patch, is specifically about NPAPI.

Comment 27 by Deleted ...@, Jan 29 2014

This issue is clearly not fixed, as ads are still not blocked.
I'm getting this issue on both Chrome stable and Chrome Canary.Adblock is broken. The ads are irritating. Needs fixing soon before I ditch Chrome and move to Firefox.

PS - Cannot use the built in flash player as performance is SIGNIFICANTLY worse, especially when gaming.

Comment 29 Deleted

Comment 30 Deleted

Comment 31 by Deleted ...@, Feb 13 2014

Still broken. Still getting ads.
Labels: Restrict-AddIssueComment-EditIssue
Locking to comments, since spamming the bug with "still broken" without any technical details or version information isn't useful. Comment 19 seems like strong indication that the fix did in fact cause there to be enough information for the extension to work. If anyone has *actual technical details* demonstrating that this is not true *in a version with the patch*, then please file a new bug.

Sign in to add a comment