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

Steps to reproduce the problem:
1. Start Chromium with a clean profile (otherwise if you've visited Twitter recently, the following behaviour might not be observed).
2. Install the demo extension (files attached), which prints webRequest events to the console.
3. Open the extension's background page.
4. Visit https://twitter.com.
5. Filter the console events by the string "opensearch".
6. Note the frame ID and resource type in the event information Chromium supplies when Twitter's OpenSearch description document is loaded:

webRequest.onBeforeRequest: {"0":{"frameId":-1,"method":"GET","parentFrameId":-1,"requestId":"498","tabId":9,"timeStamp":1470171814816.284,"type":"other","url":"https://twitter.com/opensearch.xml"}}

What is the expected behavior?
The tab ID from which the request originates is correct, but the frame ID should be 0 (i.e., the top-level frame): the request for https://twitter.com/opensearch.xml was triggered by an element in the DOM of frame ID 0 (https://twitter.com), and Chromium ought to inform extensions that this is the case via the webRequest API. It'd also be nice to have a resource type for OpenSearch-related requests (perhaps "search"?) rather than simply "other".

What went wrong?
The frame ID is -1, and the resource type is a nondescript "other".

Did this work before? N/A 

Chrome version: 52.0.2743.82  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 22.0 r0

Other resources may be defined inside an OpenSearch definition document (e.g. images, favicons), and it's not clear whether Chromium retrieves them at the same time as the definition document. If it does, the frame ID for those resources' events in the webRequest API should be accounted for in the same way.

Note that this bug report doesn't relate to the OpenSearch-related webRequest activity that occurs as a result of typing into the omnibox after the document has been parsed: the webRequest tab/frame IDs for that activity is -1/-1, which is what I'd expect (because those requests are generated by the browser chrome, rather than any particular web page frame).