Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 18 users
Status: Fixed
Closed: Dec 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Sign in to add a comment
webRequest.onBeforeRequest wrongly labels request of type 'object' as type 'other'
Reported by, Sep 3 2014 Back to list
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce the problem:
1. Go to
2. Embedded video will start to play automatically

What is the expected behavior?
Embedded video doesn't start to play automatically

What went wrong?
The real problem is that With Chrome 38 beta and 39 dev, I see that ALL requests which should be reported as type `object` by the webRequest.onBeforeRequest API are now reported as being of type `other`.

WebStore page:┬Áblock/cjpalhdlnbpafiamejdnhcphjbkeiagm

Did this work before? Yes Chrome 37 stable

Chrome version: 39.0.2138.3 dev-m  Channel: n/a
OS Version: 7
Flash Version:

Other extensions will also be broken:
- Adblock Plus
- AdBlock

And who knows how many which rely on net requests from within a plug-in being of type `object` and not `other`.
Problem of wrong request type extended to image type with Chromium 39.0.2159.4: it appears images of type GIF and JPG are wrongly typed as `other` (PNG are properly typed as `image`.
In the engadget example you gave, I think it may be a Flash problem.  I'm using Adblock Plus and noticed the video auto-starting initially but then I disabled Flash and it didn't auto-start any more.  That coincides with the versions you gave too because Chrome 37 uses Flash 14 while Chrome 39 uses Flash 15.
I don't understand your comment: yes, if you disable Flash, it obviously won't run. The problem is the webRequest API not setting properly the `type` property. In Chrome 38+, all requests of type `object` are reported as type `other`. This breaks extensions which expect requests from plugin to be reported as `object` by the webRequest API.
Forgot to mention the video you linked is HTML 5.  It plays with or without Flash.  I think Flash may be intercepting that property before it gets to the extension though.  Just try disabling it and see if it fixes your problem.  Since you only provided that one example, I tested it and confirmed Flash was the culprit there.
Comment 5 Deleted
Comment 6 Deleted
[reposted because of typo]

Alright, I will try to reiterate the real issue here, to be sure it's not drowned in the noise: in the webRequest.onBeforeRequest API, in Chromium 37-, requests of type `object` are reported as type `object`. In Chromium 38+, the exact same requests are reported as type `other`.

The link a posted above was merely to show a case where this causes a concrete problem, not to debate why the video starts or does not start: this specific problem reported by a user is I found the main issue here, hence why I linked to it.

Very specifically:

- Have Flash enabled.
- Have the extension installed.
- Go in the Statistics tab in above mentioned extension, and enable network request logging.
- Visit any web page for which there is a Flash plugin (or I suspect *any* type of plugin)
- Open the Statistics tab for the visited page, and select the page in the drop down list.


Chrome 37-: many requests of type `object`.

Chrome 38+: ***same requests*** are now labelled as `other`.

That is the bug I am reporting.
Comment 8 by, Sep 19 2014

I am currently avoiding upgrading from the working version of Chromium Version 39.0.2145.4 (8f3c881c091a8eb8bc9df2ed45e11a4ed35e628a) (64-bit)
just because of this issue.

Labels: Needs-Bisect
Status: Untriaged
Unable to reproduce this on Win7/64 bit - 37.0.2062.120 (Official Build 281580) m & Version 39.0.2159.4 dev-m (64-bit).

I am able to reproduce this on Canary - Version 39.0.2162.0 canary (64-bit)

I have followed the steps given in the description above.
Comment 11 by, Sep 20 2014
This seems like a good reason as any for me to start building chromium directly from source and do a bisect. I will read the instruction as to how to do that(on Manjaro/Arch Linux) and report back after I manage to do the bisect.

starting with these:

I can reproduce with version 39.0.2159.4 dev-m (32-bit).
Labels: -Cr-Platform-Extensions Cr-Platform-Extensions-API M-39
Status: Assigned
#11 em4cz3: You might find it easier to use the Chromium bisect-builds tool:
(It bisects over pre-built binaries so you don't need to check out or build the source.)

Assigning to battre for triage purposes. Please reassign if there is a more appropriate person to look at it. Thanks!
Comment 14 by, Sep 24 2014
Labels: -Pri-2 -Type-Bug -OS-Windows -Needs-Bisect Pri-1 Type-Bug-Regression OS-All
Reproducible on latest M-39(39.0.2167.4) across all the platforms as well.

Steps followed:
1.Added the Adblock plus extension from the CWS(URL:
2.Navigated to

Expected:Embedded video should not play untill user plays it.
Actual: Emabedded video stars playing without any user action.

Bisect tool invoked all the good builds,hence unable to provide the tool result.Updating the narrow,manual good and bad builds.
Bad :38.0.2101.0


Unable to zero-in to the culprit CL.
Status: Started
In we translate from content::ResourceType to strings. We need to introduce a mapping for content::RESOURCE_TYPE_MEDIA.
Owner: ----
Status: Available
I cannot reproduce this under Linux. I see strange resource types on Windows but don't have time to look into this at the moment (I'd need to setup a working environment for this). Marking this as available.
Comment 17 by, Sep 24 2014
Just for my record, if I manage to have a look later: the symptoms are similar to the past  issue 128347 .
By the way, I worked around the issue in the latest version of the extension mentioned in OP. To reproduce with the same extension, load manually version from here:
Comment 19 by, Sep 26 2014
I was able to reproduce this issue on my Win machine, with Chrome stable (36) working as expected and Canary (39) showing the bug.
For easy testing I created the attached extension.
I hope to find time to look into this next week, but will not assign this to me until I do, not to block this.
1.1 KB Download
Comment 20 by, Sep 26 2014
To correct the info from #19, tested versions were:
37.0.2062.124 (Official Build 281580) stable working as expected
39.0.2169.3 (Official Build) canary showing the bug
Comment 21 by, Sep 26 2014
Confirmed this also on Ubuntu with Chromium builds:
39.0.2144.0 (Developer Build 73bd924d3996) shows the bug
38.0.2071.0 (Developer Build 280003) works OK

Note: to get the Pepper Flash plugin with Chromium, use --ppapi-flash-path=<path to your flash> (you can get that path in about:plugins of a Google Chrome instance, in my case it was /opt/google/chrome-beta/PepperFlash/

Let me see if I can get a narrower bisect using the Chromium builds.
Comment 22 by, Sep 26 2014
Status: Assigned
Bisect done:
You are probably looking for a change made after 284440 (known good), but no later than 284446 (first known bad).

Suspecting r284445, so over to Mike! :)
It's not r284445 as far as I can tell.  As that commit was a one-liner I just reverted it on tip of tree, rebuilt, and I'm still showing the bug.

Sorry about any confusion caused by my earlier comments by the way.  I was having trouble understand the bug but I'm now able to reproduce it.
Comment 24 by, Sep 29 2014
@dbdaniel42: Doing a revert on ToT is no longer possible, after another related CL of mkwst (r285530, landed. I'm not sure what you meant by revert, but I'm doubt you did not get the code into the pre-r284445 state with the setTargetType() call (did you?). The bisect indentified the range of #22 without doubt, and from those handful of CLs, r284445 seems the only one touching Pepper and request types.

Having said that, Mike seems more knowledgeable to judge, so leaving that up to him.
Comment 25 by, Sep 29 2014
Sorry for the typos:
"I'm doubt you did not get the code into the pre-r284445 state"
"I doubt you got the code into the pre-r284445 state"
Thanks for pointing me to this, Vaclav. I thought Dominic had picked it up, but he's buried. :)

I could imagine the CL you've pointed to causing problems for the WebRequest API. Did the API previously categorize requests from a plugin (as opposed to requests for the initial SWF) as being OBJECT? This CL changed that.

I don't think it has anything to do with the previous complaint that GIFs are being categorized as OTHER. We don't subcategorize image requests so far as I know (except <picture> vs <img>, but those are both mapped to the IMAGE type). Is there any more detail available about the cases in which that happens?
Comment 27 by, Oct 2 2014
Labels: Needs-Feedback
Marking as feedback needed, because the 3rd paragraph of #26 is a question directed to those experiencing the failure.

I can try to find an answer to the 2nd paragraph, but if some of the extension developers know the answer straight away, please speak up. :)
Prior to Chrome 38 both, requests initiated by flash objects, and the request loading the initial SWF were categorized as "object".

With the current development build (Chrome 39) also images and stylesheets are categorized as "other". I reproduced this on Debian.
Comment 29 by, Oct 6 2014
Labels: -Needs-Feedback
Thanks for the answer in #28. You write "also images...", so I understand that even the initial request for the flash object is categorised as "other" (that's what I have seen as well).

Mike -- do you know why the requests for the flash objects would be categorised as "other"?

I'm not sure what to do about the requests initiated by flash objects, but would tend towards keeping the old behaviour (categorising as "object" as well) in order not to break expectations. What do you think?
Comment 30 by Deleted ...@, Oct 9 2014

I have made a few observations concerning this issue. Some versions of Chrome have worked and then with a later version the issue reappears. This also seems to correspond to Flash being updated. Pardon me as I am not as tech savvy as most here but just wanted to point these observations out just in case they may help. If you need my system specs and Chrome channel: Windows 8.1.1 Pro 64 bit running latest Chrome 64 bit dev versions. Here are my observations over the past few weeks:

This issue first appeared to me with Chrome 39.0.2159.4 dev-m (64-bit), no issues with previous versions. I am not 100% positive (maybe 95%), but I think Flash was also updated with this version of Chrome.

With Chrome 39.0.2171.2 dev-m (64-bit), the issue went away. Flash was also updated to version The issue stayed fixed for a few Chrome releases (with which there were no Flash updates).

With Chrome 40.0.2182.3 dev-m (64-bit), the issue returned. At this time, Flash was also updated to version

This may or may not just be a coincidence but here is what I have observed:
Whether the issue is present or not does not always correspond to a new version of Chrome but has always since it appeared on my system corresponded to a new version of Flash.

Like I said, this could be just a coincidence but I thought I should report this pattern that I have observed. It seems this issue could very well be related to the Pepper Flash versions and not necessarily the version of Chrome. Hope this helps.....

Also there is a discussion of this issue over on GitHub here:
that you may want to read...
Comment 31 Deleted
Comment 32 by Deleted ...@, Oct 15 2014

An update on my post # 30 above...

Today Chrome 40.0.2188.2 dev-m (64-bit) was released and Flash was not updated (still version The issue in this thread is fixed again with this version of Chrome, so I guess this answers my question about coincidence (Flash appears not to be involved).

I am not tech savvy enough to do "bisects" and I do not use the canary versions (only use the released 64-bit dev versions on Windows 8.1.1). I can offer the following observations though:
Prior to Chrome 39.0.2159.4 dev-m (64-bit) - No Issues.
With Chrome 39.0.2159.4 dev-m (64-bit) - Issue first appeared on my system.
With Chrome 39.0.2171.2 dev-m (64-bit) - No Issues.
With Chrome 40.0.2182.3 dev-m (64-bit) - Issue reappeared, broken again.
With Chrome 40.0.2188.2 dev-m (64-bit) - No Issues.....
I hope this may help to narrow down whatever it is that keeps breaking and then fixing as far as this issue is concerned...
The issue has already been identified here:

The fix is just the two lines of change in patch set #1.  I tested it and it fixed this bug for me.  They seem to be having problems with the rest of the patch which is an automated test to ensure this regression doesn't happen again.
For reference, images and stylesheets are identified with their correct type again, as of 39.0.2171.36 (beta) and 40.0.2194.2 (dev).
Any chance this bug will be fixed in Chrome 40?
Project Member Comment 36 by, Dec 17 2014
The following revision refers to this bug:

commit c3e50e6354188999da307094c5c037d5933f1bc3
Author: mkwst <>
Date: Wed Dec 17 12:31:02 2014

Map WebURLRequest::RequestContextPlugin to RESOURCE_TYPE_OBJECT.

The WebRequest API should treat both object requests, and requests made
from those objects (e.g. Flash requesting an .mp4 resource) as type
Object. We used to do this, then I broke it. :( Now I'm fixing it. :)

BUG= 410382

Review URL:

Cr-Commit-Position: refs/heads/master@{#308787}


Apparently the fix has just been reverted, because it might cause browser
test PDFExtensionTest.BasicPlugin to fail. Any chance to get that issue resolved?
Comment 38 by, Dec 10 2015
Status: Started
Project Member Comment 39 by, Dec 22 2015
The following revision refers to this bug:

commit 6a32a203bbae04ef29a42f3f364ec00a0adf9179
Author: rob <>
Date: Tue Dec 22 19:46:51 2015

WebRequest API: add more resource types

Added new resource types "font" and "ping" to identify fonts, <a ping>
and navigator.sendBeacon requests. Existing types are also extended:
Workers (web workers, shared workers, service workers) are mapped to
"script" and favicons are mapped to "image". Plugin requests are also
labeled as "object".
(all of these mentioned requests were previously labeled as "other").

Added two resource types:
- RESOURCE_TYPE_CSP_REPORT; Previously RequestContextCSPReport mapped to
  RESOURCE_TYPE_PING. ping and beacons are commonly used for tracking,
  whereas CSP reports aid the security of website owners. By not
  including CSP reports in the ping type, extensions that disable ping
  will not inadvertently block security features of a website.

- RESOURCE_TYPE_PLUGIN_RESOURCE; plugin requests should be tagged as
  "object" instead of "other". But we cannot use RESOURCE_TYPE_OBJECT
  because this is used by MimeTypeResourceHandler::SelectNextHandler to
  determine whether to intercept the resource and display the result in
  a plugin.

BUG= 80230 , 410382 , 512406 

Review URL:

Cr-Commit-Position: refs/heads/master@{#366632}


Comment 40 by, Dec 23 2015
Status: Fixed
As of Chrome 49, object subresources are labeled as "object" again. This is already available on Canary for Mac, Windows will follow soon.
Comment 41 by, May 12 2016
To webRequest API users who rely on resource type "ping":

Please take a look at issue 611453 ( - there is a request to not classify sendBeacon requests as "ping".
Comment 42 by, May 13 2016
Sign in to add a comment