webRequest: add property to event data indicating which navigation the resource is for
Reported by
ch...@chrisn.me.uk,
Aug 11 2016
|
||||||
Issue descriptionChrome version: 52.0.2743.116 (64-bit) When a frame navigates from document #1 to document #2, there is a short period between the webNavigation.onBeforeNavigate event for document #2 (when the navigation "begins", or as close to that point as possible from an extension's point of view) and the webNavigation.onCommitted event for document #2 (when Chromium has committed to abandoning document #1 for document #2). During this period, there's no way for extensions listening for webRequest API events to be sure whether resources are being loaded because of something in document #1, or because Chrome is preloading content for document #2. Here's an example that makes the problem more concrete: 1. Install the demo extension (files attached), which prints webNavigation and webRequest events to the console. 2. Open the extension's background page. 3. Visit the example at https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_unknown_frame_navigation/ - this page contains an iframe (iframe-1.html) that contains a stylesheet and runs a script that loads an image inside the iframe every 25ms; after 3 seconds, a script running in the main frame navigates the iframe to a second page (iframe-2.html) that does the same thing, but for different stylesheet and image URLs. 4. Note the ambiguity in the webRequest events between iframe-2.html's webNavigation.onBeforeNavigate and webNavigation.onCommitted events: there are webRequest events for iframe-2.html, iframe-resource-1.gif and (sometimes) iframe-2-stylesheet.css with the correct tab and frame IDs, but no indication of which of the navigations they "belong" to: the one for iframe-1.html, or the one for iframe-2.html. This issue therefore prevents a Chromium extension from properly auditing the behaviour of documents, i.e. accurately reporting which resources they load. One way to solve this would be to add a property to the event object for event listeners in the webRequest API that indicates whether the resource is being loaded for the document currently displayed in the frame, or (in the case where the frame is potentially undergoing a navigation) the document about to replace it - presumably Chromium itself knows this information, it just doesn't currently expose it via the webRequest API.
,
Aug 12 2016
This is more about extension APIs than navigation.
,
Aug 13 2016
Related: bug 157919 Firefox kind of solves the problem of identification by adding the originUrl property to events - https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onBeforeRedirect
,
Aug 13 2016
Having the originUrl property would certainly be useful (and it's probably something that Chromium wants anyway: it's my understanding that Chromium and Firefox are striving for parity across the extension APIs), although it wouldn't solve the problem in every case - e.g. when a frame reloads, the old and new URLs are the same, but different documents may be (and often are) served each time.
,
Aug 14 2016
The patch for bug 544114 makes the network stack aware of the originator's origin (i.e. the "http://host:port" part of "http://host:port/path..."). Would exposing this address your needs?
,
Aug 14 2016
Based on my reading of the MDN documentation for originUrl, I think it's the entire frame URL rather than just the origin that gets reported - assuming that Chromium's going for WebExtensions feature parity with Firefox, is that something Chromium would want to replicate? Even so, we'd need slightly more than that, unfortunately, because of the possibility of the URLs being the same on both sides of the navigation - we'd like to be as accurate as possible with assigning the responsibility for loading a resource, if that information's available behind the scenes.
,
Aug 15 2016
You are observing an implementation detail of Chrome's multiprocess/multithreaded architecture. Unfortunately, I don't think we include the full URL of the originating document with each request, so it will be hard to expose it through the API and will be a performance hit too. Note: I'm not an owner of the webRequest API, so just chiming in with an opinion.
,
Aug 16 2016
Thanks for the background, Nasko - I'm not too familiar with Chromium's architecture, so that's helpful to know. I appreciate that the frame information is of limited interest to extensions - if we're talking about a potentially large performance hit, would it be possible to expose the frame information we're looking for only if a certain string is given in the opt_extraInfoSpec array, as is currently the case with "blocking" to make webRequest events synchronous (presumably this was also done to prevent synchronous webRequest events causing too large a performance hit)?
,
Aug 18 2016
Is this now the official bug for the details.originUrl property on webRequest extension API? Or should we open a new one? I'm looking for this property as well, but for reasons different from the original post.
,
Aug 19 2016
,
Aug 21 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
,
Aug 21 2017
This is still important to us, and the current state of the webRequest API is such that the behaviour reported in the original report hasn't changed. If someone could reopen this issue, I'd appreciate it.
,
Aug 21 2017
(Actually, it seems that it's still open: perhaps a status change from Untriaged back to Available?)
,
May 15 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by tkonch...@chromium.org
, Aug 12 2016