Proposal: documentId in tabs.query() filter#586
Conversation
rdcronin
left a comment
rdcronin
left a comment
There was a problem hiding this comment.
(Very belated) thank you for the PR! There's a few extra pieces here we should polish out, but I am generally supportive of this change.
| ** How to Use This Template ** | ||
|
|
||
| See [Proposal Process](proposal_process.md) for the detailed process on how to | ||
| propose new APIs and use this template. Each section includes instructions on | ||
| what to include. Delete the instructions for a given section once it's filled | ||
| out. Remove this section once the template is filled out. | ||
|
|
There was a problem hiding this comment.
Remove this section, per instructions
| ** How to Use This Template ** | |
| See [Proposal Process](proposal_process.md) for the detailed process on how to | |
| propose new APIs and use this template. Each section includes instructions on | |
| what to include. Delete the instructions for a given section once it's filled | |
| out. Remove this section once the template is filled out. |
| time-of-check-time-of-use bugs. Currently extension may query tabs based on | ||
| only incidental identifiers like `windowId`, `index`, and if extension has | ||
| powerful `"tabs"` permission, then also `title` and `url`. Such checks are | ||
| inherintly cumbersome for the extension developer, may lead to extension |
There was a problem hiding this comment.
| inherintly cumbersome for the extension developer, may lead to extension | |
| inherently cumbersome for the extension developer, may lead to extension |
| browsing session. | ||
| 3. If `documentId` is provided and valid, then `tabs.query()` returns only the | ||
| tab which hosts the corresponding document in a top-level context and | ||
| matching all other filters. (In particular, if `documentId` corresponds to |
There was a problem hiding this comment.
I'm curious about this (the subframe behavior). It seems like being able to query which tab holds a document could be useful, independent of if it's a main frame or subframe (e.g., for querying which tab holds a particular frame that the extension may have injected into via a scripting API).
Curious for other folks' thoughts on this. Should we limit this to top frames?
| tab which hosts the corresponding document in a top-level context and | ||
| matching all other filters. (In particular, if `documentId` corresponds to | ||
| sub-frame, an empty list is returned, matching current implementation.) | ||
|
|
There was a problem hiding this comment.
I think we also need to specify the behavior for other unusual cases, such as:
- prerendered documents
- cached (bfcache) documents
- documents in a (web) popup
- documents in an (extension) popup
etc
| ### Exposed Sensitive Data | ||
|
|
||
| Document ids correspond to unique page loads, so a compromised or malicious | ||
| extension could infer page navigations by polling `tabs.query()` untill a |
There was a problem hiding this comment.
| extension could infer page navigations by polling `tabs.query()` untill a | |
| extension could infer page navigations by polling `tabs.query()` until a |
|
|
||
| Document ids correspond to unique page loads, so a compromised or malicious | ||
| extension could infer page navigations by polling `tabs.query()` untill a | ||
| particular document appears or disappers to conclude back-forth navigation. |
There was a problem hiding this comment.
| particular document appears or disappers to conclude back-forth navigation. | |
| particular document appears or disappears to conclude back-forth navigation. |
|
@bershanskiy this was briefly discussed in London today. What are your thoughts on some of the suggestions from Devlin? Sidenote, should be great to also allow passing an array. Happy to assist with getting this somewhere. |
3 participants
This formalizes proposal first described in #553.
Relevant links