Proposal: allow specifying documentId for devtools.inspectedWindow.eval()

[bershanskiy]

Split out form #389.

Currently, developers can execute code in a frame identified by a URL. Issue #389 notes that it might be more convenient to use frameId, especially when there are multiple frames with the exact same URL. However, in some circumstances frameId is actually inconvenient to use and documentId would be better.

For example:

• frame can host the same document but the URL may change dynamically
• frame can host multiple different documents and navigate between them
• at least in Chrome, early in prerender process, document can have a non-zero frameId but then be moved to a top-level frame with frameId set to 0

[Rob--W]

@oliverdunk Google's opinions on this (in relation to #389)?

@xeenon What's Safari's position here?

Firefox's position: sounds reasonable, if we were to implement this. The use of documentId instead of frameId would help against a TOCTOU issue that I described in #8. frameId would still be useful for cases where extensions don't know about the documentId but do know about the frameId.

[dotproto]

Just opened #434 on the WebDriver BiDi repo to discuss whether it makes sense to integrate the concept of documentID in that specification.

[oliverdunk]

@Rob--W Adding follow-up: chrome while I confirm with the team about any implementation details with this sort of thing in the DevTools API (which isn't strictly an extension API). Assuming we can support frame ID though I think it makes sense to do this too.

[oliverdunk]

Having discussed this with the team, we are generally supportive. There may be some complexity around exposing these extension concepts in the implementation (which lives alongside DevTools), and this wouldn't be high priority for us, but we're open to it.