Documentation should say chrome.webRequest listeners added with {tabId: -1} are called for all requests
Reported by
natalie....@gmail.com,
May 18 2016
|
||||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0
Steps to reproduce the problem:
1. Add webRequest listeners with {tabId: -1} in an extension's background script:
var eventNames = [
"onBeforeRequest",
"onBeforeSendHeaders",
"onSendHeaders",
"onHeadersReceived",
//"onAuthRequired",
"onResponseStarted",
"onBeforeRedirect",
"onCompleted"
];
function listener(name, details) {
console.log(name, details.tabId, details.url, details);
}
eventNames.forEach(function (name) {
chrome.webRequest[name].addListener(
listener.bind(null, name),
{urls: ["<all_urls>"], tabId: -1}
);
});
2. Load any URL in any browser tab.
What is the expected behavior?
No messages should be logged. Only requests from extension background scripts and popups should be logged.
What went wrong?
The listeners log all requests, as if `tabId` were omitted when the listener was added.
Did this work before? N/A
Chrome version: <Copy from: 'about:version'> Channel: stable
OS Version:
Flash Version:
The documentation [1] doesn't actually say what should happen. I'm assuming that listeners for {tabId: -1} should only be called with {tabId: -1} in its argument.
I've also assumed that only background script and popups are the source of {tab: -1} request events, but idk. The documentation should elaborate.
,
May 20 2016
natalie.grrossman@Could you please provide sample file with actual and expected behavior screencast for better understanding the issue to triage it further.
,
May 20 2016
Screencasts? Seriously? Sure, I'll get right on that.
The component is "Platform>Extensions>API", the issue is with `chrome.webRequest.on*.addListener` filters, the problem is that a {tabId: -1} filter results in no filtering whatsoever. A Chrome extension demonstrating the problem is attached. Inspect the extension's background page and confirm that the listeners are being called for {tabId: anything}.
I omitted the reference URL in my original post; apologies.
[1] https://developer.chrome.com/extensions/webRequest#type-RequestFilter
,
May 21 2016
Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 24 2016
Tested the issue on Ubuntu 14.04, Windows 7, Mac 10.11.5 using 50.0.2661.102, canary 53.0.2746.0 with below steps: 1.Added given 'bug_webrequest_filter' unpacked extension in chrome://extensions. 2.Clicked on link 'background page'. 3.Observed that the background page opened with console result as in attached screenshot. Please find attached screenshot and confirm if this is the issue. natalie.grrossman@Could you please provide expected behavior screenshot for further triaging the issue.
,
May 24 2016
No, it is not the issue. The issue is only evident after "2. Load any URL in any browser tab."
In the example extension, `chrome.webRequest` listeners are added with a filter `{tabId: -1}`. They should not be called unless `tabId` is -1 in the argument to the event callback.
The attached screenshot shows my listeners logging events for {tabId: -1} (correct; circled in green) but also for {tabId: 39} (incorrect; circled in red) when the Google newtab page loads in a new tab. Any tabId except -1 is incorrect here.
(1) This is an *extension* issue, not an *app* issue. Different APIs, yes?
(2) It is not a "BackgroundPage" issue, it is a Chrome extension API issue. Specifically, it's a problem with `chrome.webRequest.on*` and/or `chrome.webRequest.on*.addListener` (supra)
(3) It afflicts all of the various `chrome.webRequest.on*` events.
(4) If you erase every entry in my screenshot for which 'tabId' is not '-1', you have the expected behavior screenshot.
Attached screenshot is of:
Chromium 50.0.2661.102 (Developer Build) Ubuntu 14.04 (32-bit)
,
May 25 2016
Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 26 2016
,
May 27 2016
Overloaded meaning of tabId in play here... In WebRequest RequestFilter's context tabId -1 means "everything". We should document that in https://developer.chrome.com/extensions/webRequest#type-RequestFilter
,
May 28 2016
Are you sure? That seems more like a bug than a design feature. `{tabId: undefined}` also means "everything", as does omitting `tabId` altogether. It seems perfectly silly to specify `{tabId: -1}` and then have to test for `tabId == -1` in the listener anyway.
Also, a little off-topic, but is there a way to catch and change headers for just my extension's pages (for which `tabId == -1`) without changing the requests for other extensions' pages (for which `tabId == -1`)?
,
May 28 2016
Oh, you hijacked my bug report. How rude.
,
May 30 2016
Issue 615640 has been merged into this issue.
,
May 30 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 7 2017
I'm confused, is this bug going to be ignored? -1 used to designate the background_script, but now it just designates nothing? Why would -1 be used but not null? This decision to make -1 mean "unrelated to a tab" is completely arbitrary and damaging I filed a duplicate of this bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=759897&can=1&q=reporter%3Awarent&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by natalie....@gmail.com
, May 18 2016