Sunggook Chue would like Guido Urdaneta to review this change.
Add placeholder of speaker-selection permission.
Incorporating the ‘speaker-selection’ permission from
'https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/speaker-selection'
this addition aligns with Chromium’s permission enhancements
(https://source.chromium.org/chromium/chromium/src/+/main:components/permissions/add_new_permission.md)
However, it’s important to note that this feature is not yet implemented in
the chrome://settings/content page. Additionally, the need for a permission
prompt remains uncertain (not edited related code), and use 'test' permission
policy to prevent unintended prompts outside of testing scenarios."
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This is a placeholder, not enabled yet all.
Thanks fore reviewing!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The general structure looks good (modulo removal of unrelated files), but obviously it needs to be reviewed by the proper owners.
Once it's ready, please send me a follow-up CL where you make use of the new permission to authorize/block speaker swtiches (made via the setSinkId() API).
case PermissionType::SPEAKER - SELECTION:Should this be `SPEAKER_SELECTION`?
```suggestion
case PermissionType::SPEAKER_SELECTION:
```
// Avoid recording the setting; it is not really associated withSpeaker selection is not about capture, but about playout.
Note also that the way Chromium works right now is that if you have the microphone permission, you automatically gain an equivalent of this permission (e.g., to be able to switch output to a headset if you change capture to the headset mic)
// Copyright 2024 The Chromium AuthorsIt looks like this file, and the corresponding .cc shouldn't be part of this CL.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Should this be `SPEAKER_SELECTION`?
```suggestion
case PermissionType::SPEAKER_SELECTION:
```
Done
// Avoid recording the setting; it is not really associated withSpeaker selection is not about capture, but about playout.
Note also that the way Chromium works right now is that if you have the microphone permission, you automatically gain an equivalent of this permission (e.g., to be able to switch output to a headset if you change capture to the headset mic)
I will replace this "
// TODO: Implement this method.
// The current speaker selection permission comes from the
// microphone permission at this time. Initially, we can continue
// to use the microphone permission for top frame, but follow
// the spec for iframes."
What's is your idea how user can get speaker-selection permission in the top frame (when HTTP response header does not grant its permission);
It looks like this file, and the corresponding .cc shouldn't be part of this CL.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// TODO: The current speaker selection permission comes from thereference a bug inside the TODO.
Also, the wording is a bit confusing.
There is no current speaker selection permission (you are implementing it).
What exists is implicit consent via getUserMedia() for the setSinkId() API, which is part of the spec ("Implementations MUST also support implicit consent via the getUserMedia() permission prompt" [1]).
The specific permission will allow the implementation of other parts of the spec.
[1] https://w3c.github.io/mediacapture-output/#privacy-obtaining-consent)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sunggook Chue would like Balazs Engedy, Peter Beverloo, Chromium IPC Reviews and Florian Jacky to review this change.
Add placeholder of speaker-selection permission.
Incorporating the ‘speaker-selection’ permission from
'https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/speaker-selection'
this addition aligns with Chromium’s permission enhancements
(https://source.chromium.org/chromium/chromium/src/+/main:components/permissions/add_new_permission.md)
However, it’s important to note that this feature is not yet implemented in
the chrome://settings/content page. Additionally, the need for a permission
prompt remains uncertain (not edited related code), and use 'test' permission
policy to prevent unintended prompts outside of testing scenarios."
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
gwsq would like Tom Sepez to review this change authored by Sunggook Chue.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
From googleclient/chrome/chromium_gwsq/ipc/config.gwsq:
IPC: tse...@chromium.org
📎 It looks like you’re making a possibly security-sensitive change! 📎 IPC security review isn’t a rubberstamp, so your friendly security reviewer will need a fair amount of context to review your CL effectively. Please review your CL description and code comments to make sure they provide context for someone unfamiliar with your project/area. Pay special attention to where data comes from and which processes it flows between (and their privilege levels). Feel free to point your security reviewer at design docs, bugs, or other links if you can’t reasonably make a self-contained CL description. (Also see https://cbea.ms/git-commit/).
IPC reviewer(s): tse...@chromium.org
Reviewer source(s):
tse...@chromium.org is from context(googleclient/chrome/chromium_gwsq/ipc/config.gwsq)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// TODO: The current speaker selection permission comes from thereference a bug inside the TODO.
Also, the wording is a bit confusing.
There is no current speaker selection permission (you are implementing it).
What exists is implicit consent via getUserMedia() for the setSinkId() API, which is part of the spec ("Implementations MUST also support implicit consent via the getUserMedia() permission prompt" [1]).
The specific permission will allow the implementation of other parts of the spec.
[1] https://w3c.github.io/mediacapture-output/#privacy-obtaining-consent)
Thanks for clarification, I've updated comments based on your comment here.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
case PermissionType::SPEAKER - SELECTION:Still broken here.
Sunggook, can you please specify which set of files you would like each owner to review? I see that you have added Florian and myself as well, I wonder if he already has context on this change?
| Code-Review | +1 |
MOJO LG but it looks like there's a typo preventing this from building.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sunggook Chue would like Theodore Olsauskas-Warren, Fredrik Söderquist, Andrey Kosyakov and Sami Kyöstilä to review this change.
Sunggook Chue removed Florian Jacky from reviewers of this change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
add reviewers:
Andrey: t/b/p/d/browser_protocol.pdl, c/b/d/p/browser_handler.cc
Peter B: a/b/aw_permission_manager.cc, t/m/h/m/histogram_suffixes_list.xml
Theodore: c/b/u/w/s/site_settings_helper.cc
Balazs: c/b/p/permission_controller_* , c/c/c/b/content_settings_registry.*, permission_util.*, third_party/blink/renderer/modules/permissions/ permission_utils.cc
Sami K: t/b/r/p/runtime_enabled_features.json5
Tom S: c/c/c/c/content_settings_types.mojom
case PermissionType::SPEAKER - SELECTION:Sunggook ChueStill broken here.
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Does this have an associated intent?
return "speaker_selection";It looks like this ought to be "speaker-selection" to match what's in PermissionName - since it's exposed via the `PermissionStatus` IDL interface and there expected to match the enumeration. (I see that the spec is loosey-goosey about this and just has a DOMString, but it seems a UA should at the very least be self-consistent at the very least.)
| Code-Review | +1 |
permissions and content_settings LGTM % comments below.
void SpeakerSelectionPermissionContext::UpdateContentSetting(Can you please instead follow suit with the approach in chrome/browser/display_capture/display_capture_permission_context.cc that overrides all methods necessary for not crashing if PermissionController::RequestPermission* is called?
return "speaker_selection";It looks like this ought to be "speaker-selection" to match what's in PermissionName - since it's exposed via the `PermissionStatus` IDL interface and there expected to match the enumeration. (I see that the spec is loosey-goosey about this and just has a DOMString, but it seems a UA should at the very least be self-consistent at the very least.)
Indeed, please use dashes for consistency (as pointed out in the TODO above). There are indeed some historical mistakes, the reason they are still there is because they are hard to change due to web compat risk.
| Code-Review | +1 |
chrome/browser/ui/webui/settings/site_settings_helper.cc LGTM
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
void SpeakerSelectionPermissionContext::UpdateContentSetting(Can you please instead follow suit with the approach in chrome/browser/display_capture/display_capture_permission_context.cc that overrides all methods necessary for not crashing if PermissionController::RequestPermission* is called?
Done
Balazs EngedyIt looks like this ought to be "speaker-selection" to match what's in PermissionName - since it's exposed via the `PermissionStatus` IDL interface and there expected to match the enumeration. (I see that the spec is loosey-goosey about this and just has a DOMString, but it seems a UA should at the very least be self-consistent at the very least.)
Indeed, please use dashes for consistency (as pointed out in the TODO above). There are indeed some historical mistakes, the reason they are still there is because they are hard to change due to web compat risk.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Somehow, all votes are reset, can you take a look this change again?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Code-Review | +1 |
| Code-Review | +1 |
| Code-Review | +1 |
// Whether an application can enumerate audio output device.nit: devices.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Sunggook Chue would like Daniel Bratell, Ian Clelland and Nicola Tommasi to review this change.
Add placeholder of speaker-selection permission.
Incorporating the ‘speaker-selection’ permission from
'https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/speaker-selection'
this addition aligns with Chromium’s permission enhancements
(https://source.chromium.org/chromium/chromium/src/+/main:components/permissions/add_new_permission.md)
However, it’s important to note that this feature is not yet implemented in
the chrome://settings/content page. Additionally, the need for a permission
prompt remains uncertain (not edited related code), and use 'test' permission
policy to prevent unintended prompts outside of testing scenarios."
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Nicola for WebsitePermissionsFetcherTest.java,
Ian for Permissions_policy_features.json5, feature_policy.dict
Daniel for t/b/r/p/runtime_enabled_features.json5.
Thanks,
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Sunggook Chue would like Ari Chivukula and Kevin Ellis to review this change.
Sunggook Chue removed Ian Clelland from reviewers of this change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Adding Ari and Kevin for t/b/r/c/p/feature_policy.dict. Thanks.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
LGTM for feature dict specific changes, did not look elsewhere (trusting others on overall design)
| Commit-Queue | +2 |
Add placeholder of speaker-selection permission.
Incorporating the ‘speaker-selection’ permission from
'https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/speaker-selection'
this addition aligns with Chromium’s permission enhancements
(https://source.chromium.org/chromium/chromium/src/+/main:components/permissions/add_new_permission.md)
However, it’s important to note that this feature is not yet implemented in
the chrome://settings/content page. Additionally, the need for a permission
prompt remains uncertain (not edited related code), and use 'test' permission
policy to prevent unintended prompts outside of testing scenarios."
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |