UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0

Steps to reproduce the problem:
1. Create a webRequest listener with a filter `{tabId: -1}` (or `{tabId: chrome.tabs.TAB_ID_NONE}`) in the background script of an extension. Have the listener log requests for which `tabId != -1`:

// manifest.json
{
  "manifest_version": 2,
  "name": "Bug: webRequest filter `{tabId: -1}` passes `tabId !== -1` events",
  "version": "1.0",
  "background": {
    "scripts": ["background.js"]
  },
  "permissions": ["webRequest", "<all_urls>"]
}

// background.js
chrome.webRequest.onBeforeRequest.addListener(
  function (details) {
    if (details.tabId !== -1) console.warn("Oops! tabId:", details.tabId, details.url);
  },
  { tabId: -1, urls: ["<all_urls>"] }
);

2. With the extension installed and enabled, browse to a page in any tab.
3. Inspect the extension's background page. In the Console are logged webRequest events for which `tabId !== -1`.

What is the expected behavior?
There should be no events logged in the console.

What went wrong?
A filter of `{tabId: -1}` acts as if no `tabId` filter is present. It acts as if the filter were omitted, or as if the filter were `{tabId: undefined}`.

Did this work before? N/A 

Chrome version: 50.0.2661.102  Channel: stable
OS Version: 
Flash Version: 

I've been told (Issue 612967) that `tabId` as a filter value and `tabId` as an event value mean two different things. If true, it is absurd and unnecessary, and the behavior should be rationalized. 

Alternative `{tabId: any}` filter values are already available. One can simply omit the `tabId` filter altogether, or can pass `undefined` as its value.

A `{tabId: chrome.tabs.TAB_ID_NONE}` is not the same as `{tabId: any}`, and is useful in its own right when listening for requests initiated by extension pages and other tabless requesters. (Are there other tabless requesters? idk)