6

I'm writing a Chrome extension that periodically checks a web-page on the user's behalf. To be unobtrusive, the page is loaded into an iframe on the extension's hidden background page. Is it possible to identify just the web requests made by this iframe?

My initial experiments (see below) seem to indicate that this is tricky. Getting all web requests for a particular tab is easy: you have the tabId, and can filter web requests (via the WebRequest API) with that tabId. But for a background-page iframe, it's unclear what the "tabId equivalent" identifier is, or how to use it to filter web requests.

Any thoughts?

My initial experiment details are below. The frameId value looked promising, but I don't believe it's unique across extensions.

This question has already been asked for Firefox: Identify requests originating in the hiddenDOMWindow (or one of its iframes)

== Experiment ==

As an experiment, I:

  • Listened for all web requests with the WebRequest API
  • Created an iframe on the extension's background page, and opened a url.

Here's a captured iframe web request:

{
  "frameId": 2,
  "method": "GET",
  "parentFrameId": 0,
  "requestId": "11988",
  "tabId": -1,
  "timeStamp": 1395423892612.272,
  "type": "sub_frame",
  "url": "http://en.wikipedia.org/wiki/Frog"
}

The tabId and parentFrameId values look suspect.

The frameId value looks promising. If we knew the frameId of the frame, could we use that to filter requests?

Possibly, but the frameId value isn't unique across browser extensions. I created another identical extension, and got its background iframe to load the same url. It generated an identical looking request, with identical frameId (for its own - but different - iframe). Also, this Chromium issue refers to "frame id collisions": https://code.google.com/p/chromium/issues/detail?id=173325

Community
  • 1
  • 1
huczilla
  • 953
  • 1
  • 9
  • 11

1 Answers1

2

State of Affairs

Hi - struggling through a similar problem and here's what I've found:

The tabId and parentFrameId values look suspect.

Check out the documentation for the details object returned to WebRequest callback handlers:

  • tabId is set to -1 when there's no tab (like in a background page).
  • since extensions are in their own processes 0 indicates the parent is your top-level frame

Using chrome.tabs you can actually get a tabId for a background page but unfortunately, as you've found, WebRequest always gives -1 for a tabId

Generally, it seems as though WebRequest was going to be deprecated in favor of DeclarativeWebRequest but development of the latter is currently on pause.

Potential real solution:

I haven't tested this but it's possible that only requests made from your background page will be available to you and have a tabId of -1. You could potentially filter for these.

Hacky solution:

  1. Inject a frame onto an actual page within a tab with a known destination URL. The URL could even be a web-accessible URL within your extension to avoid collision.
  2. Extension-side keep track of the tabId and frameId that generated that request.
  3. Within the iframe load the actual page that you're interested in (either via a redirect or by having the content of the iframe be another iframe to the page).
  4. Use the stored tabId and frameId (available as the requests parentId) to decide which requests to filter.
Community
  • 1
  • 1
MrChrisRodriguez
  • 493
  • 6
  • 12