Publish minutes of 2024-11-07 meeting #720
Open
+230
−4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dotproto
requested changes
Nov 7, 2024
| * [rob] Don't think we need to break down this issue. Root cause is that it's not possible to select which partition will be used to make a request. There are some not well documented mechanisms available in Chrome. It would be nice if there was a way to make a request from the right partition. | ||
| * [simeon] I believe we've discussed a way of selecting a partition to make a request before. Aaron may have some additional thoughts. | ||
| * [aaron] Specifically selecting the partition for a frame? Within the cookies API, we are defining the cookies.getPartitionKey method to retrieve the partition for a frame, including the topLevelSite and hasCrossSiteAncestor. | ||
| * [rob] That would provide a way to query the partition,but doesn't give us a way to specify the partition for a given request. Two approaches: make sure the extension iframe is loaded in the right partition. Another is to provide a dedicated API for the extension to make a request from a given partition. Need to get feedback from browser vendors on preferred approach. |
There was a problem hiding this comment.
Suggested change
| * [rob] That would provide a way to query the partition,but doesn't give us a way to specify the partition for a given request. Two approaches: make sure the extension iframe is loaded in the right partition. Another is to provide a dedicated API for the extension to make a request from a given partition. Need to get feedback from browser vendors on preferred approach. | |
| * [rob] That would provide a way to query the partition,but doesn't give us a way to specify the partition for a given request. I see two approaches: make sure the extension iframe is loaded in the right partition. Another is to provide a dedicated API for the extension to make a request from a given partition. Need to get feedback from browser vendors on preferred approach. |
| * [oliver] In this case, the third-party context is a frame. In the extension document there's an iframe with a third party site. You'd want to change which partition that embedded frame uses. | ||
| * [patrick] In this case it's specifically an embedded frame from the Adobe CDN. | ||
| * [rob] In that case I don't think we should allow it to select a different partition, because that iframe is regular web content. | ||
| * [aaron] Sounds like requestStorageAccess would be useful for. Inside the frame the extension could call this. If the cookie is a third party unpartitioned cookie we could potentially provide access to that. This is an area I work with often. requestStorageAccess is a purely JS API. As long as the iframe can use JS it could use this. We can follow up. |
There was a problem hiding this comment.
Suggested change
| * [aaron] Sounds like requestStorageAccess would be useful for. Inside the frame the extension could call this. If the cookie is a third party unpartitioned cookie we could potentially provide access to that. This is an area I work with often. requestStorageAccess is a purely JS API. As long as the iframe can use JS it could use this. We can follow up. | |
| * [aaron] Sounds like requestStorageAccess would be useful for this. Inside the frame the extension could call this. If the cookie is a third party unpartitioned cookie we could potentially provide access to that. This is an area I work with often. requestStorageAccess is a purely JS API. As long as the iframe can use JS it could use this. We can follow up. |
| * [patrick] In this case it's specifically an embedded frame from the Adobe CDN. | ||
| * [rob] In that case I don't think we should allow it to select a different partition, because that iframe is regular web content. | ||
| * [aaron] Sounds like requestStorageAccess would be useful for. Inside the frame the extension could call this. If the cookie is a third party unpartitioned cookie we could potentially provide access to that. This is an area I work with often. requestStorageAccess is a purely JS API. As long as the iframe can use JS it could use this. We can follow up. | ||
| * [oliver] Might be best to post on the issue. That said, not purely a cookies issue. They're looking to apply DNR rules. Doesn't seem like this is the ideal way to solve this for |
There was a problem hiding this comment.
Suggested change
| * [oliver] Might be best to post on the issue. That said, not purely a cookies issue. They're looking to apply DNR rules. Doesn't seem like this is the ideal way to solve this for | |
| * [oliver] Might be best to post on the issue. That said, not purely a cookies issue. They're looking to apply DNR rules. Doesn't seem like this is the ideal way to solve this for the general case. |
| * [tomislav] The result of the proposal would be a new kind of state where the extension in installed and working but doesn't have access to all the required permissions from the manifest. If we want to open that can of worms, that can be useful for other things as well. That would require extensions to code against that. So far the presumption has been that if it's a required permission it's always available. This would break that model. | ||
| * [timothy] I'm also concerned that developers won't checking permissions.contains() at runtime. | ||
| * [patrick] Nobody requested this as the default behavior, opt in is preferred. | ||
| * [simeon] … |
There was a problem hiding this comment.
Suggested change
| * [simeon] … | |
| * [simeon] The current model assumes required permissions are granted. If they can sometimes be optional, developers will need to approach all permissions added after the first public release as potentially optional. Can no longer guarantee that a required permission has been granted. |
| * [patrick] Nobody requested this as the default behavior, opt in is preferred. | ||
| * [simeon] … | ||
| * [patrick] Impression I got was that this would be an upgraded permission. A fresh install would treat the permission as required. Permissions would only be treated as optional in an upgrade. | ||
| * [simeon] Extensions should develop as if all permissions are optional. (...) No guarantee that the contract with the platform won't change and the “required” permissions won't be treated as optional in the future. |
There was a problem hiding this comment.
Suggested change
| * [simeon] Extensions should develop as if all permissions are optional. (...) No guarantee that the contract with the platform won't change and the “required” permissions won't be treated as optional in the future. | |
| * [simeon] Extensions should develop as if all permissions are optional. Safest to assume required permissions may not be granted and code defensive. If this contract changes, no guarantee that the contract with the platform won't change further and the “required” permissions won't be treated as optional in the future. |
| * [rob] Feature request for the ability to retrieve the element that is clicked when a context menu was opened. Firefox solved this by introducing getTargetElement(). When contextMenus.onClicked fires you can get a reference (targetElementId) that you pass to the menus.getTargetElement function in a content script to retrieve the element. There are workarounds such as exposing the coordinates in the document, but they're lossy. Firefox's approach is a reliable solution. | ||
| * [timothy] Against coordinate suggestion as well; interested in implementing Firefox's getTargetElement API. | ||
| * [oliver] Treating this as opaque is fine, but I'm curious what this ID looks like in Firefox. | ||
| * [rob] It's generated in Firefox. I believe it's the timestamp. On click, a weak ref to the element is stored, timestamp is captured and passed to the extension. |
There was a problem hiding this comment.
Suggested change
| * [rob] It's generated in Firefox. I believe it's the timestamp. On click, a weak ref to the element is stored, timestamp is captured and passed to the extension. | |
| * [rob] It's a generated number in Firefox. I believe it's the timestamp. On click, a weak ref to the element is stored, timestamp is captured and passed to the extension. |
| * [rob] It's generated in Firefox. I believe it's the timestamp. On click, a weak ref to the element is stored, timestamp is captured and passed to the extension. | ||
| * [oliver] Thanks, just wanted to understand the general shape. | ||
| * [timothy] I'd want it to be opaque. UUID or some string. | ||
| * [rob] It's currently an integer. This enables extensions to pass the value to getTargetElement in a code string (tabs.executeScript) without serialization concerns. That concern is lesser in MV3 because scripting.executeScript does not accept code strings, and accepts args for func instead. |
There was a problem hiding this comment.
Suggested change
| * [rob] It's currently an integer. This enables extensions to pass the value to getTargetElement in a code string (tabs.executeScript) without serialization concerns. That concern is lesser in MV3 because scripting.executeScript does not accept code strings, and accepts args for func instead. | |
| * [rob] It's currently an integer. This enables extensions to pass the value to `getTargetElement` in a code string (`tabs.executeScript`) without serialization concerns. That concern is lesser in MV3 because `scripting.executeScript` does not accept code strings, and accepts `args` for `func` instead. |
|
|
||
| [Issue 717](https://github.com/w3c/webextensions/issues/717): Request: [ContextMenus] Include `<canvas>`s in the "page" ContextType (or it's own ContextType) | ||
|
|
||
| * [simeon] The only way to match <canvas> elements is to specify “all”. The request is to offer a specific contextType to match <canvas>. |
There was a problem hiding this comment.
Suggested change
| * [simeon] The only way to match <canvas> elements is to specify “all”. The request is to offer a specific contextType to match <canvas>. | |
| * [simeon] The only way to match `<canvas>` elements is to specify “all”. The request is to offer a specific `contextType` to match `<canvas>`. |
| * [simeon] Sounds like we're aligned? | ||
| * [rob] I'd like to see more details on use cases. One of the comments was to support a CSS selector to match context menus by selector. That would be a more general way to support this capability. I'm generally in favor of CSS selector. I'm opposed to adding “canvas” ContextType when there is no special context associated with it. | ||
| * [timothy] We'd still have the issue of needing getTargetElement to meaningfully interact with the element | ||
| * [simeon] Agreed, I think we're discussing which solution to issue 717 is the right approach. |
There was a problem hiding this comment.
Suggested change
| * [simeon] Agreed, I think we're discussing which solution to issue 717 is the right approach. | |
| * [simeon] Agreed, I think we're discussing which solution to issue #717 is the right approach. |
| * [rob] I'd like to see more details on use cases. One of the comments was to support a CSS selector to match context menus by selector. That would be a more general way to support this capability. I'm generally in favor of CSS selector. I'm opposed to adding “canvas” ContextType when there is no special context associated with it. | ||
| * [timothy] We'd still have the issue of needing getTargetElement to meaningfully interact with the element | ||
| * [simeon] Agreed, I think we're discussing which solution to issue 717 is the right approach. | ||
| * [timothy] I'm in favor of “canvas” context type because it is simpler than matching by CSS selector. |
There was a problem hiding this comment.
Suggested change
| * [timothy] I'm in favor of “canvas” context type because it is simpler than matching by CSS selector. | |
| * [timothy] I'm in favor of “canvas” context type because it is simpler than matching by CSS selector. Not worried about API bloat if this case later becomes addressable with selector matching. |
|
I have not applied these changes to the Google Doc. |
xeenon
reviewed
Nov 8, 2024
| @@ -0,0 +1,40 @@ | |||
| # WECG Meetings 2024, Public Notes, Oct 24 | |||
|
|
|||
| * Chair: Timothy Hatcher | |||
There was a problem hiding this comment.
Suggested change
| * Chair: Timothy Hatcher | |
| * Chair: Simeon Vincent |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Generated from https://docs.google.com/document/d/1QkwhEMtMS67JBUkl_WVPZ4lRSKoWcQNlLJSf_GwSXg8/edit using the tool and process from #105.
During this meeting we discussed or mentioned issues #718, #531, #708, #711, #713, #715, #716, #717, #719, #527, #532, #501 and PR #546.
In this PR I also included the brief meeting notes of the previous canceled meeting (#709), because I never created a PR for it.