Re: [blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute

[Marcos Caceres]

On Wednesday, March 20, 2024 at 4:57:56 AM UTC+11 Sanket Joshi (Edge) wrote:

Hi Marcos,

The spec for the writing suggestions attribute 
<https://html.spec.whatwg.org/#writing-suggestions> doesn't specify how UAs 
should implement writing suggestions under the hood, it just aims to 
provide developers with a way to control whether the writing suggestions 
are shown on their site or not. 


Right, but I think what we missed in the spec is describing how this plays 
with input events, and composition events, which is where this is now 
causing issues. 
 

I don't think this attribute or its on-by-default state carries inherent 
compat risk. 


It might if the predictive text fires events and participates in the DOM 
(as it does in WebKit). 
 

I think any compat issues/quirks would depend on the implementation of 
writing suggestions, which will vary from browser to browser. I responded 
in the Github issue too, but we'll likely need to get to the bottom of what 
is breaking those sites with Safari's implementation of writing 
suggestions. We can continue discussions on Github.


Yes, let's do that. Just think that because we didn't discuss input and 
composition events as part of standardization, we might have overlooked 
this aspect. 

Again, it depends on how this is implemented... like floating bubbles 
on-top of text might not fire events... but combining this with input and 
composition events seems to have issues. We might have been overly 
ambitious on the WebKit side making it participate in the composition / 
event set of events, but not sure. 
 


Thanks,
Sanket
On Tuesday, March 19, 2024 at 12:02:18 AM UTC-7 yoav...@chromium.org wrote:

Thanks for the heads up, Marcos! :)

On Tue, Mar 19, 2024 at 3:51 AM Marcos Caceres  wrote:

Hi Blink-Dev Friends!

We (WebKit) hit some web compat issues with this feature while testing our 
implementation is Safari Tech Preview. 

Could you please take a look at:
https://github.com/whatwg/html/issues/10209

And see if there is a way to leave this on by default somehow without 
affecting websites? 

Looking forward to discussions. 
Marcos 

On Friday, March 15, 2024 at 9:29:19 AM UTC+11 sligh...@chromium.org wrote:

LGTM3

On Thursday, March 14, 2024 at 2:59:45 PM UTC-7 Mike Taylor wrote:

LGTM2
On 3/14/24 12:43 AM, Domenic Denicola wrote:

Awesome! LGTM1.

On Thu, Mar 14, 2024 at 1:35 PM 'Stephanie Zhang' via blink-dev <
blin...@chromium.org> wrote:

Thanks for clarifying! Updated the Chrome Status' "Finch Feature Name" 
field to kWritingSuggestions and removed the "Non-finch justification" 
field. 

On Wednesday, March 13, 2024 at 9:20:57 PM UTC-7 Domenic Denicola wrote:

On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via blink-dev <
blin...@chromium.org> wrote:

We do have a runtime feature flag 'WritingSuggestions 
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5?q=writingsuggestions>'.
 
We didn't think a Finch Trial was necessary, as the bulk of the changes were 
just adding the attribute and IDL functions 
<https://chromium-review.googlesource.com/c/chromium/src/+/5247315>. Since 
everything is implemented on the blink side, is a Finch feature flag still 
necessary? If it is, then I'll add that flag :)


A runtime feature flag automatically generates 
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;l=121-125;drc=36168a902bb7a33bfc8b46ad1f4ef6672872ad6d>
 
a Finch flag, unless you turn that off :). So I think this is just a matter 
of updating the Chrome Status entry.
 


On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic Denicola wrote:



On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:

*Contact emails*
*sa...@microsoft.com*, *dan...@microsoft.com*, 
*stephanie.zh...@microsoft.com*

*Explainer*
*https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*
 
<https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md>

*Specification*
*https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions* 
<https://html.spec.whatwg.org/multipage/interaction.html>

*Summary*
UAs are starting to provide writing suggestions to users as they type on 
various editable fields across the web. While this is generally useful for 
users, there are cases when developers may want to turn off UA-provided 
writing assistance, such as extensions or sites that wish to provide 
similar functionality on their own. To that end, developers need a solution 
that would turn on/off UA-provided writing assistance. The new attribute 
'writingsuggestions' has values 'true'/'false' that would allow developers 
to turn on/off browser-provided writing suggestions. The attribute's state 
for an element can also be inherited from ancestor elements, thereby 
allowi

Re: [blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute

[Marcos Caceres]

Hi Blink-Dev Friends!

We (WebKit) hit some web compat issues with this feature while testing our 
implementation is Safari Tech Preview. 

Could you please take a look at:
https://github.com/whatwg/html/issues/10209

And see if there is a way to leave this on by default somehow without 
affecting websites? 

Looking forward to discussions. 
Marcos 

On Friday, March 15, 2024 at 9:29:19 AM UTC+11 sligh...@chromium.org wrote:

> LGTM3
>
> On Thursday, March 14, 2024 at 2:59:45 PM UTC-7 Mike Taylor wrote:
>
>> LGTM2
>> On 3/14/24 12:43 AM, Domenic Denicola wrote:
>>
> Awesome! LGTM1.
>>
>> On Thu, Mar 14, 2024 at 1:35 PM 'Stephanie Zhang' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>> Thanks for clarifying! Updated the Chrome Status' "Finch Feature Name" 
>>> field to kWritingSuggestions and removed the "Non-finch justification" 
>>> field. 
>>>
>>> On Wednesday, March 13, 2024 at 9:20:57 PM UTC-7 Domenic Denicola wrote:
>>>
 On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via blink-dev <
 blin...@chromium.org> wrote:

> We do have a runtime feature flag 'WritingSuggestions 
> '.
>  
> We didn't think a Finch Trial was necessary, as the bulk of the changes 
> were 
> just adding the attribute and IDL functions 
> . 
> Since everything is implemented on the blink side, is a Finch feature 
> flag 
> still necessary? If it is, then I'll add that flag :)


 A runtime feature flag automatically generates 
 
  
 a Finch flag, unless you turn that off :). So I think this is just a 
 matter 
 of updating the Chrome Status entry.
  

>
> On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic Denicola 
> wrote:
>
>>
>>
>> On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:
>>
>> *Contact emails*
>> *sa...@microsoft.com*, *dan...@microsoft.com*, 
>> *stephanie.zh...@microsoft.com*
>>
>> *Explainer*
>>
>> *https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*
>>  
>> 
>>
>> *Specification*
>>
>> *https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions*
>>  
>> 
>>
>> *Summary*
>> UAs are starting to provide writing suggestions to users as they type 
>> on various editable fields across the web. While this is generally 
>> useful 
>> for users, there are cases when developers may want to turn off 
>> UA-provided 
>> writing assistance, such as extensions or sites that wish to provide 
>> similar functionality on their own. To that end, developers need a 
>> solution 
>> that would turn on/off UA-provided writing assistance. The new attribute 
>> 'writingsuggestions' has values 'true'/'false' that would allow 
>> developers 
>> to turn on/off browser-provided writing suggestions. The attribute's 
>> state 
>> for an element can also be inherited from ancestor elements, thereby 
>> allowing developers to control this functionality at a per-element or 
>> per-document/sub-document scale.
>>
>>
>> *Blink component*
>> *Blink>Editing* 
>> 
>>
>> *TAG review*
>> *https://github.com/w3ctag/design-reviews/issues/924* 
>> 
>>
>> *TAG review status*
>> Issues addressed
>>
>> *Risks*
>>
>>
>> *Interoperability and Compatibility*
>> None
>>
>>
>> *Gecko*: No signal (
>> *https://github.com/mozilla/standards-positions/issues/855* 
>> )
>>
>> *WebKit*: In development (
>> *https://github.com/WebKit/standards-positions/issues/308* 
>> ) WebKit 
>> Implementation PR: *https://github.com/WebKit/WebKit/pull/24051* 
>> 
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> *Ergonomics*
>> None
>>
>>
>> *Activation*
>> None
>>
>>
>> *Security*
>> None
>>
>>
>> *WebView application risks*
>> *Does this intent deprecate or change behavior of existing APIs, such 
>> that it has 

Re: [blink-dev] Intent to Ship: web-share permission policy

[Marcos Caceres]

Hi Blink-Dev friends,
 
Over on the WebKit side we published a PSA for developers about the 
permission policy change:
https://webkit.org/blog/13708/allowing-web-share-on-third-party-sites/

As this change affects all browsers and quite a few sites, it would be 
amazing if folks doing developer relations on the Blink side could help 
spread the word through your dev channels.

Thanks in advance! 

On Tuesday, November 22, 2022 at 7:14:46 PM UTC+11 mk...@chromium.org wrote:

> LGTM3.
>
> -mike
>
> On Friday, November 18, 2022 at 4:24:43 PM UTC+1 Mike Taylor wrote:
>
>> LGTM2. I think we should expect some compat issues with this change, but 
>> they're currently the ones experienced by Safari and Firefox:
>>
>> https://github.com/jsbin/jsbin/issues/3485
>> https://github.com/webcompat/web-bugs/issues/105859
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1737541 (see bugs in "See 
>> also")
>>
>> Do we have any plans to make the developer community aware of the need to 
>> delegate web-share permission to iframes now? Maybe a blog post in the 
>> works?
>>
>> On 11/18/22 4:25 AM, Yoav Weiss wrote:
>>
> LGTM1
>>
>> Thanks for catching us up here! :)
>>
>> On Thu, Nov 17, 2022 at 11:18 PM Eric Willigers  
>> wrote:
>>
>>> Contact emails
>>> ericwi...@chromium.org, fin...@chromium.org
>>>
>>> Explainer
>>> https://github.com/w3c/web-share/blob/master/docs/explainer.md
>>>
>>> Specification
>>> https://w3c.github.io/web-share/#permissions-policy
>>>
>>> Summary
>>> A new permission policy, "web-share", controls access to 
>>> navigator.share().
>>>
>>> The default allowlist is 'self', avoiding possible abuse by third party 
>>> iframes.
>>> Link to blink-dev discussion
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/fgme9KOd8CU/m/TCYPKQAXAwAJ
>>>
>>> Blink component
>>> Blink>WebShare 
>>> 
>>>
>>> TAG review
>>> Not needed, trivial change to existing spec
>>>
>>
>> A better reasoning would be that we're aligning to shipped behavior in 
>> other engines.
>>  
>>
>>
>>> TAG review status
>>> Not applicable
>>>
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility 
>>>
>>> navigator.share() is called by embedded iframes. These may expect 
>>> share() calls to succeed, when now they will fail if permission has not 
>>> been granted.
>>>
>>> Firefox has successfully shipped the feature.
>>>
>>> Failures were observed with YouTube, these have now been addressed. 
>>>
>>>
>>>
>>> Gecko: Shipped/Shipping (https://github.com/w3c/web-share/pull/252)
>>>
>>> WebKit: Shipped/Shipping (https://github.com/w3c/web-share/issues/169) 
>>> CL recently merged: 
>>> https://github.com/WebKit/WebKit/commit/ded7a6094a6ca38833e63a7915b7b6a2832f5734
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>> WebView application risks 
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> N/A - Web Share API is not enabled in WebView.
>>>
>>>
>>> Debuggability
>>> No DevTools changes needed.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> No
>>>
>>> The Permissions Policy will be supported on all platforms that support 
>>> Web Share API. Currently, this is Android, Chrome OS, Windows.
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?
>>> Yes
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?
>>> False
>>>
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1079104
>>>
>>> Sample links
>>> https://scrawny-bottlenose-somersault.glitch.me/share-from-iframes.html
>>>
>>> Estimated milestones
>>> M110
>>>
>>> Anticipated spec changes
>>>
>>> -
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6362499966304256
>>>
>>>
>>> This intent message was generated by Chrome Platform Status 
>>> .
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to blink-dev+unsubscr...@chromium.org.
>>
>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4303ef1-c709-4f90-b97b-e2fc4b0f2e2bn%40chromium.org
>>>  
>>> 
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>>
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+unsubscr...@chromium.org.
>>
>> To view this discussion on the web 

Re: [blink-dev] Intent stage "Evaluate readiness to ship": web-share permission policy

[Marcos Caceres]

Fantastic to hear! I’ve put up the the WebKit patch and hope to land it by the 
end of the week:
https://github.com/WebKit/WebKit/pull/6074

I also refactored the tests a little bit if anyone has a few cycles to review:
https://github.com/web-platform-tests/wpt/pull/36862/files

(I need to make some small changes to get them to run on WebKit Infra, plus 
found some missing conditions). 

> On 9 Nov 2022, at 5:02 pm, Eric Willigers  wrote:
> 
> The YouTube issue has been addressed. We can ship with default "self" in 
> M110. crrev.com/c/3995946
> 
> On Tuesday, June 14, 2022 at 3:55:04 PM UTC+10 mar...@marcosc.com wrote:
> Hi All, 
> 
> On Wednesday, June 8, 2022 at 12:05:48 PM UTC+10 Matt Giuca wrote:
> Hi folks,
> 
> I've followed up on this internally at Google (talking to Chrome and YouTube 
> people) and also had a private thread with Marcos.
> 
> Marcos has proposed just changing the spec (and by extension, Gecko) to make 
> the permission policy be "*" by default, essentially codifying Chrome and 
> Safari's current behaviour of allowing embeds to use Web Share without 
> permission, but giving embedders the option to explicitly block it:
> https://github.com/w3c/web-share/pull/234 
> My preference is actually to try and enforce the current spec (default of 
> "self") which would mean YT and other embeds are blocked from using Web Share 
> by default, unless granted permission by the embedder.
> 
> 'self' is my preference also and I'd be more than happy to close the PR for 
> the proposal above (#234). Short of removing the permissions policy entirely, 
> #234 was basically the only means we had to deal with the web compat issues 
> that have arisen. 
> 
> But it's super encouraging to hear "self" could be back on the table.  
> 
> As I see it, the only major issue with YouTube being a huge user of Web Share 
> in iframes, is that the share button is apparently broken (as in, if clicked, 
> it throws a JS exception) if the permission is blocked. That's simply a bug 
> which we can get YouTube to fix (I am following up internally with YouTube). 
> If that bug is fixed, then I don't see a problem with the share button 
> falling back to use the internal in-page share UI (rather than using the Web 
> Share API) on the majority of embedded YT videos, with the option for 
> embedders to grant the permission if they want that UI to work.
> 
> Either way, we should come to a consensus on this and align the spec and 
> three implementations in relatively short order (O(days-weeks)).
> 
> That would be amazing. In the meantime, we've updated WebKit to use "*" as I 
> was left with little option because of the breakage.
> 
> However, if we get agreement on "self" and some kind of timeframe form 
> Chrome, I can revert that form WebKit and we can work towards an 
> interoperable solution ('self'). 
> 
> FWIW, Firefox is also shipping with 'self' as the policy [1], which means 
> it's also affecting their Windows and Android implementations.
> 
> [1] 
> https://github.com/mozilla/gecko-dev/blob/1e13dfc1bd87c3747d6712807401c590d0211a46/dom/security/featurepolicy/FeaturePolicyUtils.cpp#L37
>   
> Looking forward to a speedy resolution! 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/D892766F-8D60-4706-B131-AE81760996F1%40marcosc.com.

[blink-dev] Seeking feedback on element proposal

[Marcos Caceres]

Hi Blink-Dev / Chromium folks, 

WebKit project is seeking input into our recently proposed HTML  
element, which was submitted for incubation to the Immersive Web CG at the 
W3C. 

We have an explainer that outlines the motivation (and tries to answer how 
this is different to using WebGL, lowering barrier of entry, potential use 
cases, etc.): 
https://github.com/immersive-web/model-element/blob/main/explainer.md

And the *very rough* makings of a spec (mostly just red boxes outlining all 
the potential issues we've identified so far):
https://immersive-web.github.io/model-element/

We'd love to get your feedback, either here or as issues filed in the 
repository:
https://github.com/immersive-web/model-element/issues

We know that trying to standardize  is going to be a significant 
undertaking with a lot of challenges, but we are really excited about 
bringing this new capability to Web. Looking forward to getting your 
feedback and collaborating on incubating it! 

Kind regards,
Marcos
 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4d49d61-f1ac-4249-9f21-95a2697d7c31n%40chromium.org.

Re: [blink-dev] Intent stage "Evaluate readiness to ship": web-share permission policy

[Marcos Caceres]

Hi All, 

On Wednesday, June 8, 2022 at 12:05:48 PM UTC+10 Matt Giuca wrote:

> Hi folks,
>
> I've followed up on this internally at Google (talking to Chrome and 
> YouTube people) and also had a private thread with Marcos.
>
> Marcos has proposed just changing the spec (and by extension, Gecko) to 
> make the permission policy be "*" by default, essentially codifying Chrome 
> and Safari's current behaviour of allowing embeds to use Web Share without 
> permission, but giving embedders the option to explicitly block it:
> https://github.com/w3c/web-share/pull/234 
>

> My preference is actually to try and enforce the current spec (default of 
> "self") which would mean YT and other embeds are blocked from using Web 
> Share by default, unless granted permission by the embedder.
>

'self' is my preference also and I'd be more than happy to close the PR for 
the proposal above (#234). Short of removing the permissions policy 
entirely, #234 was basically the only means we had to deal with the web 
compat issues that have arisen. 

But it's super encouraging to hear "self" could be back on the table.  

As I see it, the only major issue with YouTube being a huge user of Web 
> Share in iframes, is that the share button is apparently broken (as in, if 
> clicked, it throws a JS exception) if the permission is blocked. That's 
> simply a bug which we can get YouTube to fix (I am following up internally 
> with YouTube). If that bug is fixed, then I don't see a problem with the 
> share button falling back to use the internal in-page share UI (rather than 
> using the Web Share API) on the majority of embedded YT videos, with the 
> option for embedders to grant the permission if they want that UI to work.
>
> Either way, we should come to a consensus on this and align the spec and 
> three implementations in relatively short order (O(days-weeks)).
>

That would be amazing. In the meantime, we've updated WebKit to use "*" as 
I was left with little option because of the breakage.

However, if we get agreement on "self" and some kind of timeframe form 
Chrome, I can revert that form WebKit and we can work towards an 
interoperable solution ('self'). 

FWIW, Firefox is also shipping with 'self' as the policy [1], which means 
it's also affecting their Windows and Android implementations.

[1] 
https://github.com/mozilla/gecko-dev/blob/1e13dfc1bd87c3747d6712807401c590d0211a46/dom/security/featurepolicy/FeaturePolicyUtils.cpp#L37
  

Looking forward to a speedy resolution! 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a965fc70-f24f-49f4-8ddf-378e7730f02cn%40chromium.org.

Re: [blink-dev] Intent stage "Evaluate readiness to ship": web-share permission policy

[Marcos Caceres]

Just checking in again  I'm wondering if by chance folks here might be to 
ping the YouTube folks one last time? It's been a while, so maybe they will 
respond this time? 

Also, if we can try to get some cross-browser resolution around permission 
policy for Web Share, it would be really great.   

On Friday, May 20, 2022 at 6:36:22 PM UTC+10 Marcos Caceres wrote:

> Hi All, 
>
> Coming back to this as it's now starting to cause Web compatibly issues 
> across both Firefox and SafariTP (both of which implement `'self'`). 
>
> I'm still worried that the ability to share files and other content (and 
> even URLs, as we've seen in the past) is quite a powerful feature with 
> security implications.
>
> However, we (other implementers) are facing a losing battle with Web 
> compatibly here :( 
>
> If it's too far gone, could we compromise with a "*" policy. But I'd like 
> to get again get a sense if we can go with 'self'.   
>
>
> On Monday, November 2, 2020 at 4:22:58 PM UTC+11 Matt Giuca wrote:
>
>> Pinging on this. It's been awhile and I don't think we've seen any update 
>> on it. (Nobody from YouTube responded on the internal bug.)
>>
>> Eric, did measurements land and if so, what milestone will we start 
>> seeing results in?
>>
>> On Fri, 4 Sep 2020 at 05:06, Chris Harrelson  
>> wrote:
>>
>>> Hi Eric,
>>>
>>> Did the analysis relating to Youtube complete? Do you think this will be 
>>> safe to turn on, because the Youtube case was sufficiently special?
>>>
>>> Chris
>>>
>>> On Sun, Aug 23, 2020 at 10:03 PM Eric Willigers  
>>> wrote:
>>>
>>>>
>>>> On Friday, August 21, 2020 at 5:15:18 AM UTC+10, Mike West wrote:
>>>>>
>>>>> Have you followed up with YouTube internally? As Eric notes, it seems 
>>>>> bad that this broke sharing in Canary.
>>>>>
>>>>
>>>> I have raised a YouTube issue internally, showing how to detect if 
>>>> Feature Policy forbids sharing.
>>>>
>>>>
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "blink-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to blink-dev+...@chromium.org.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e554e75c-f1cc-4a68-bac9-a7e8477c916bo%40chromium.org
>>>>  
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e554e75c-f1cc-4a68-bac9-a7e8477c916bo%40chromium.org?utm_medium=email_source=footer>
>>>> .
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/124d0a06-05d6-4248-8771-0ac15105e787n%40chromium.org.

Re: [blink-dev] Intent stage "Evaluate readiness to ship": web-share permission policy

[Marcos Caceres]

Hi All, 

Coming back to this as it's now starting to cause Web compatibly issues 
across both Firefox and SafariTP (both of which implement `'self'`). 

I'm still worried that the ability to share files and other content (and 
even URLs, as we've seen in the past) is quite a powerful feature with 
security implications.

However, we (other implementers) are facing a losing battle with Web 
compatibly here :( 

If it's too far gone, could we compromise with a "*" policy. But I'd like 
to get again get a sense if we can go with 'self'.   


On Monday, November 2, 2020 at 4:22:58 PM UTC+11 Matt Giuca wrote:

> Pinging on this. It's been awhile and I don't think we've seen any update 
> on it. (Nobody from YouTube responded on the internal bug.)
>
> Eric, did measurements land and if so, what milestone will we start seeing 
> results in?
>
> On Fri, 4 Sep 2020 at 05:06, Chris Harrelson  wrote:
>
>> Hi Eric,
>>
>> Did the analysis relating to Youtube complete? Do you think this will be 
>> safe to turn on, because the Youtube case was sufficiently special?
>>
>> Chris
>>
>> On Sun, Aug 23, 2020 at 10:03 PM Eric Willigers  
>> wrote:
>>
>>>
>>> On Friday, August 21, 2020 at 5:15:18 AM UTC+10, Mike West wrote:

 Have you followed up with YouTube internally? As Eric notes, it seems 
 bad that this broke sharing in Canary.

>>>
>>> I have raised a YouTube issue internally, showing how to detect if 
>>> Feature Policy forbids sharing.
>>>
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e554e75c-f1cc-4a68-bac9-a7e8477c916bo%40chromium.org
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6948552f-e384-461d-a5c5-13cc1fb13775n%40chromium.org.

Re: [blink-dev] Intent to Ship: PermissionStatus.prototype.name

[Marcos Caceres]

> On 20 Aug 2021, at 8:41 am, Mike Taylor  wrote:
> 
> Hey Marcos,
> 
> On 8/19/21 2:09 AM, Marcos Caceres wrote:
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=897309
> I think that's maybe a mistake, 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1236856 seems to be the 
> right bug.

Oh whoops! Copy/pasting is hard. Thanks, Mike! 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7CC232FB-D1A4-4FE5-99AC-E3AF2CD4A510%40marcosc.com.

Re: [blink-dev] Intent to Ship: PermissionStatus.prototype.name

[Marcos Caceres]

> On 20 Aug 2021, at 7:29 am, Chris Harrelson  wrote:
> 
> Can you find developer signals and link to them here? 
> https://goo.gle/developer-signals

Ah, thanks for that link! I thought "developers signals" had to be something 
different. 

This is the original issues I filed (as a web developer):
https://github.com/w3c/permissions/issues/237#issue-863480652

Here are positive signals from various folks, which includes positive signals 
from folks at Mozilla:
https://github.com/w3c/permissions/pull/248

> Is this feature fully tested by web-platform-tests?
> Yes, to the extent that it can be.
> 
> Is there an issue preventing full testability?

The feature just echo's the name of a permission that it is give (e.g. 
"geolocation"). However, not every browser implements every permission, so the 
WTP is restricted to interoperable permission names.

However, the fact that `.name` reflects the name of the query gives a fairly 
high assurance that the feature works as intended. 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A4425773-9C36-4CEE-BDFB-EAF4A90FF9DA%40marcosc.com.

[blink-dev] Intent to Ship: PermissionStatus.prototype.name

[Marcos Caceres]

*Contact emails*
mar...@marcosc.com

*Explainer*
N/A

*Specification*
https://w3c.github.io/permissions/#permissionstatus-interface

*API spec*
Yes

*Summary*
Adds a new read only attribute "name" to the `PermissionStatus` interface, 
allowing the name of the permission to be gotten after a `PermissionStatus` 
is created.

*Motivation*
When querying multiple permissions simultaneously via the Permissions API, 
it was not possible to identify which PermissionStatus was which, as they 
were lacking a way to identify them (i.e., their "name"). The only way 
around this was to use something like array order or some other external 
index, which is less than ideal.

*Blink component*
Blink > PermissionsAPI

*TAG review*
Not required.

*Risks*
*  Interoperability and Compatibility*
  Can be feature-detected by checking for the existence of the 
PermissionStatus.prototype.name.

  Chrome: No public support (only personal support).

  Gecko: Implemented, shipped in Nightly 
https://bugzilla.mozilla.org/show_bug.cgi?id=1718021

  WebKit: No signal (don't Implement Permissions API)

  Web developers: None

*Debuggability*
No special support is needed.

*Is this feature fully tested by web-platform-tests?*
Yes, to the extent that it can be.

*Flag name*
N/A

*Tracking bug*
https://bugs.chromium.org/p/chromium/issues/detail?id=897309

*Link to entry on the Chrome Platform Status*
Coming soon... 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/31cc4084-4ec7-4faf-abc4-1ea25f3fc6d9n%40chromium.org.