Re: [blink-dev] Re: Intent to Ship: Propagate request origin and redirect chain in passthrough service workers.

[Rafael Santos Silva]

This change broke a SingleSignOn login on the FOSS software Discourse. We 
have a flow like:

1. User visits forum.siteA.com, click login
2. Gets redirected to idp.siteB.com
3. Fills login details
4. Gets redirected to forum.siteA.com/session/sso_login?parameters
5. Gets redirected to forum.siteA.com/homepage

On step 4, the response includes a `set-cookie` header, with proper `HttpOnly; 
SameSite=Lax; Secure `and set. But if there is an active service worker, 
the login will fail as that cookie will be rejected by Chromium due to 
SameSite rules now.

t=2971 [st=258]COOKIE_INCLUSION_STATUS
   --> domain = "forum.siteA.com"
   --> name = "_t"
   --> operation = "store"
   --> path = "/"
   --> status = "EXCLUDE_SAMESITE_LAX, DO_NOT_WARN"

The service worker is a vanilla WorkboxJS service worker that intercepts 
all GETs with the "Network First" strategy.

Disabling the service worker or using Firefox results in a successful 
login. There is no warning in either DevTools network tab nor the console 
that the cookie was rejected. 

Chrome 96: login works
Chrome 97: login does not work
Chrome 98: login does not work

Is this expected behavior? Even if the request `GET forum.siteA.com` was 
initiated because of a redirect from a different domain, is it expected 
that Chrome will silently drop same site cookies from forum.siteA.com?

Did not post this in the 
https://bugs.chromium.org/p/chromium/issues/detail?id=1241188 because it's 
not public.
On Tuesday, November 30, 2021 at 5:27:47 PM UTC-3 wande...@chromium.org 
wrote:

> On Tue, Nov 30, 2021 at 3:24 PM Joe Medley  wrote:
>
>> >Since the first part of the change is in M97 I updated the chromestatus 
>> entry to indicate that as the release and added a note that the 
>> redirect-chain change is coming in M98.
>>
>> Is any of this feature usable in 97? 
>>
>
> Yes.  Requests without a redirect will work in M97 and get the expected 
> origin header, sec-fetch-site header, and samesite cookies.  Some 
> restrictions redirected requests will only start being applied in M98.
>  
>
>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Nov 29, 2021 at 7:11 AM Ben Kelly  wrote:
>>
>>> Thank you!
>>>
>>> FYI, I realized this morning I made one small mistake in my original 
>>> post.  The origin propagation part of this intent is actually in M97 and 
>>> the redirect chain part is in M98.  The CLs are large, so I don't really 
>>> want to do a merge if I can avoid it.  Since the first part of the change 
>>> is in M97 I updated the chromestatus entry to indicate that as the release 
>>> and added a note that the redirect-chain change is coming in M98.  Sorry 
>>> for the confusion here.
>>>
>>> Please let me know if there is any concern about this clarification.  
>>> Thanks.
>>>
>>> On Thu, Nov 25, 2021 at 1:21 AM Mike West  wrote:
>>>
 LGTM3.

 On Wed 24. Nov 2021 at 23:59 Rick Byers  wrote:

> Makes sense, thanks! Arguably almost a bugfix level change. LGTM2
>
> On Wed, Nov 24, 2021 at 5:27 PM Ben Kelly  
> wrote:
>
>>
>>
>> On Wed, Nov 24, 2021, 5:07 PM Rick Byers  wrote:
>>
>>> Ben, can you speak to the web compat implications (or absence 
>>> thereof) to this change in behavior?
>>>
>>
>> I believe the compat risk should be minimal.  This change only 
>> matters for navigation requests and many service workers will be using 
>> nav 
>> preload instead of calling fetch() themselves.
>>
>> For sites not using nav preload it's possible they will see changes 
>> in origin headers, sec-fetch-site headers, and SameSite=Strict cookies.  
>> Depending on server logic that could cause requests to be deemed unsafe 
>> by 
>> the server and fail.  However, it would match what is done without a 
>> service worker present.  Arguably the server wants to make this decision 
>> in 
>> these situations.
>>
>> If a site does not want this behavior it requires only a small 
>> service worker change to get previous behavior.  They just need to fetch 
>> the url and not the full request.  Like `fetch(evt.request.url)` instead 
>> of 
>> `fetch(evt.request)`.
>>
>>  Nov 24, 2021 at 5:03 PM Chris Harrelson  
>>> wrote:
>>>
 LGTM1

 On Wed, Nov 24, 2021 at 1:52 PM Ben Kelly  
 wrote:

> On Wed, Nov 24, 2021 at 4:40 PM Ben Kelly  
> wrote:
>
>> Interoperability and Compatibility
>>
>>
>>
>> Gecko: No signal
>>
>
> I have not filed for formal signals, but we had a TPAC session 
>  with mozilla 
> where we reached co

[blink-dev] Intent to Prototype: Focusgroup

['Benjamin Beaudry' via blink-dev]

Contact emails

bebea...@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/explainer.md

Specification



Summary

The Focusgroup feature will facilitate keyboard focus navigation using the 
keyboard arrow keys among a set of focusable elements.

Blink component

Blink>DOM

Motivation

By providing this primitive built-in the browser, authors will be able to 
provide this functionality without relying on custom solutions that often lead 
to a lack of consistency, accessibility and interoperability.

Initial public proposal

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/explainer.md

TAG review

(note might need to kick this off as an "early review" if not done already…)

TAG review status

Pending

Risks



Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Debuggability


Is this feature fully tested by 
web-platform-tests?

No


Flag name
 Doesn't exist yet, but will be added to runtime_enabled_features.json5 as 
"Focusgroup".


Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1286127

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5637601087193088

This intent message was generated by Chrome Platform 
Status.


Cheers,

Ben

-- 
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/BL0PR00MB0820DFE66371FEA5743EA92F9B529%40BL0PR00MB0820.namprd00.prod.outlook.com.

RE: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

['Anupam Snigdha' via blink-dev]

Hi Philip,

In the worst case we will be able to merge the pickling API 
changes into the EditingWG repo. 
We have a meeting this Friday with the Firefox folks to discuss the Pickling 
API as they were also interested in the 
proposal.
 If we have consensus there, then we will be able to add pickling API to the 
official clipboard spec.
Overall I think the algorithms required to implement Pickling 
API
 is included in the forked PR. There are few concerns regarding sanitization, 
but we couldn’t come to an agreement with Apple 
folks 
to standardize it. Moreover all browsers have different sanitization behavior 
in the clipboard copy/paste methods so it will be hard to change anything there 
without breaking the legacy DataTransfer APIs that use the same sanitization 
algorithms.

Thanks,
Anupam

From: Philip Jägenstedt 
Sent: Wednesday, January 12, 2022 8:42 AM
To: Anupam Snigdha 
Cc: Domenic Denicola ; Chris Harrelson 
; Daniel Bratell ; Yoav Weiss 
; blink-dev ; Alex Russell 
; Abhishek Rathi ; 
svo...@gmail.com ; ajayra...@google.com 
; Bo Cupp ; m...@google.com 
; Joshua Bell ; Victor Costan 
; Scott Low 
Subject: Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async 
Clipboard API

Hi Anupam,

Could 
https://w3c.github.io/gamepad/extensions.html
 be a model to follow here? I think it's important to write down (and test) 
what you intend to ship in something that looks like a spec. If doing that in 
the EditingWG doesn't seem tractable, then the WICG is also an option.

This seems like a fairly frustrating situation, but I hope it's clear what to 
try next. If you do feel like you're stuck with what to do with the spec, feel 
free to ask for advice here or off list.

Best regards,
Philip

On Thu, Jan 6, 2022 at 8:16 PM Anupam Snigdha 
mailto:sni...@microsoft.com>> wrote:
Re: “but I guess it did not actually include the pickling parts yet!”: It does 
include the pickling parts. See the unsanitized option in the 
ClipboardItemOptions dictionary, write unsanitized format, os specific custom 
map name and os specific custom name sections in the PR for more details.

The part that is missing is the one that you mentioned “what to do for non-text 
data types being written to the clipboard. (Ctrl+F for "This is left to the 
implementation..." in 
https://github.com/w3c/editing/pull/383/files
 .) ”

“I think it's still important to write a spec somewhere, even if the EditingWG 
does not host it” – We will be merging this into the Editing repo, but it 
wouldn’t be part of the official clipboard API spec due to disagreement with 
Apple. Looks like FF is also 
interested
 in standardizing the sanitization behavior because the legacy DataTransfer 
APIs behave the same in Chromium, FF, old Edge and IE, but since Apple opposed 
to these changes we couldn’t include it in the official clipboard API spec.

From: Domenic Denicola mailto:dome...@chromium.org>>
Sent: Thursday, January 6, 2022 11:01 AM
To: Anupam Snigdha mailto:sni...@microsoft.com>>
Cc: Domenic Denicola mailto:dome...@chromium.org>>; Chris 
Harrelson mailto:chris...@chromium.org>>; Philip 
Jägenstedt mailto:foo...@chromium.org>>; Daniel Bratell 
mailto:bratel...@gmail.com>>; Yoav Weiss 
mailto:yoavwe...@chromium.org>>; blink-dev 
mailto:blink-dev@chromium.org>>; Alex Russell 
mailto:slightly...@chromium.org>>; Abhishek Rathi 
mailto:rath...@gmail.com>>; 
svo...@gmail.com

Re: [blink-dev] Question on getting pixels from blink/renderer/modules/accessibility.

[Philip Rogers]

On Wed, Jan 12, 2022 at 8:06 AM Ramin Halavati  wrote:

> Thank you very much Philip. I will write a 1-pager on this discussion for
> posteriority and will proceed with the inside blink approach.
>
> Just as the concluding question, I have a draft CL on it (
> crrev.com/c/3370381). Would you suggest that I take a (possibly
> simplified) copy of the DataTransfer::NodeImage
> in third_party/blink/renderer/modules/accessibility, or refactor the
> existing code in DataTransfer to fit the existing and the new use case. I
> prefer the latter as it is a very delicate and complex process. If you
> agree with that, do you have any suggestions on the refactoring or I would
> just go with it and ask you to take a look after?
>

If the accessibility and drag-image code are unlikely to diverge too much,
I think it makes sense to factor out the code that creates a PaintArtifact
for a Node out of DraggedNodeImageBuilder and into a helper. This helper
could include a comment about how the painting starts from the containing
stacking context.


>
> Best,
> Ramin
>
> On Tue, Jan 11, 2022 at 6:58 PM Philip Rogers  wrote:
>
>>
>>
>> On Tue, Jan 11, 2022 at 7:42 AM Ramin Halavati 
>> wrote:
>>
>>> Thank you very much Philip,
>>>
>>> About the concern that a repaint based approach (similar to NodeImage)
>>> will not have the backgrounds or other higher level effects, can we say
>>> that on the other hand (specially since this function is explicitly
>>> querying the image for a certain node) the full-page-paint+crop approach
>>> also suffers from the possibility that the node maybe be partially covered
>>> by another node, or being out of the screen's visible area (needing
>>> scroll), or even being covered by a dialog box?
>>>
>>
>> That's correct: the full-page-crop approach will include content on top
>> of the target content, will not include the target if it is scrolled
>> offscreen, etc.
>>
>>
>>>
>>> On Mon, Jan 10, 2022 at 8:29 PM Philip Rogers  wrote:
>>>


 On Mon, Jan 10, 2022 at 6:51 AM Ramin Halavati 
 wrote:

> Thank you Philip.
>
> Since this accessibility support function is called for all renderer
> types (in ChromeOS including Arc++ and Ash), there would be a better
> consistency if we have the snapshotting code in the renderer. Therefore I
> am trying to avoid using the browser side ui::GrabViewSnapshot (as in
> DevTools), unless the alternative approach proves to be too complicated or
> unnecessarily heavy.
>
> I tried using DataTransfer::NodeImage in this draft CL
> , but my understanding is that since it
> triggers a repaint, we should make sure it is not in the middle of a
> lifecycle update to avoid conflicts. Is there a notification of a
> signal that tells when it's safe to request it?
>

 It is important that we do not introduce lifecycle violations but I
 think that may already be guaranteed from when the accessibility code runs.
 For example, AxObject::GetRelativeBounds cannot be called from within a
 lifecycle update either. You can probably just synchronously call the paint
 function you need.


> I assume it's the same for the SpoolSinglePage as it also redraws the
> image. And performance wise, can we say that as this approach triggers a
> repaint, it's heavier than the browser based snapshotting (using
> ui::GrabViewSnapshot), as the latter is using the already painted output
> and does not require a repaint?
>

 The paint code in NodeImage is really just a walk of layout
 datastructures and isn't more expensive than things like layout, style, etc
 (i.e., it's O(|layout|)). Doing this for each object would be wildly
 inefficient though.

 Expanding on the thing about this being an ambiguous problem:
 data:text/html,hello world
 The drag image for the div will only contain white and transparent
 pixels, and will not be blurred. If you want the purple background too,
 you'll want to do the full-page-paint+crop approach.


>
> Best,
> Ramin
>
> On Fri, Jan 7, 2022 at 11:06 PM Philip Rogers 
> wrote:
>
>> This is a deceptively difficult problem in general. Our paint system
>> uses the CSS definition of paint order which starts painting at stacking
>> contexts and it is challenging to exclude non-stacked siblings of a
>> non-stacked target element. Some other complications are whether ancestor
>> effects/clips should be applied, and whether content behind the target
>> should be included.
>>
>> DataTransfer::NodeImage is an attempt at this. Another option is to
>> get the entire page painted (examples: devtools uses
>> PageHandler::CaptureScreenshot and printing uses SpoolSinglePage), then
>> crop it to the target element.
>>
>> On Fri, Jan 7, 2022 at 7:01 AM 'Ramin Halavati' via blink-dev <
>> blink-dev@c

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

[Yoav Weiss]

Hey Daniel!

While searching for this intent review, I stumbled 
upon https://developer.chrome.com/blog/immutable-document-domain/ 
That's a useful piece of documentation! Thanks +Eiji Kitamura!!

This intent was just discussed at the API owner meeting (where Chris, Rego, 
Daniel, Philip, Alex, MikeT and myself were present).
This change seems risky in terms of potential breakage when looking at our 
stats, and that's even before talking about enterprises, where a lot of the 
API owners feel the risk is even higher.

Given that, here's a few potential next steps to try and reduce that risk:

   - UKM and outreach to specific large users of the API can maybe help 
   drive the usage down.
   - A deprecation period of 3 milestones feels a bit short here. Is the 
   expectation that turning on the opt-out header can be done under that 
   period?
   - A report-only mode could have allowed sites to try and enable this, 
   without risking actual breakage for their documents/properties that use 
   document.domain. This is doubly true for platforms that want to warn their 
   customers about this upcoming deprecation, but without taking risks on 
   their behalf. At the same time, it is true that they could collect 
   deprecation reports (thanks for adding those!) instead during the 
   deprecation period, which can be considered an on-by-default report-only 
   mode. Can y'all add specific guidance on deprecation reports to the 
   documentation?
   -  It'd be helpful to reach out to enterprise folks and see what their 
   responses may be for this. +Greg Whitworth.
   - This probably requires an Enterprise Policy, to reduce the risk for 
   managed installs. +bheenan@ for opinions on that front.
   - Is there a plan to eventually remove the opt-out option? Or is it the 
   plan to have it in place permanently?
   
Cheers,
Yoav


On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:

> On 12/16/21 5:52 PM, Charlie Reis wrote:
>
>
>
> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor  
>> wrote:
>>
>>> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>>>
>>> It seems more or less everyone agrees on this being a good thing, so it 
>>> mainly comes down to web compatibility.
>>>
>>> How much of the web will break, and how badly. The numbers mentioned, 
>>> 0.5% of sites set document.domain, 0.05% seem to depend on document.domain, 
>>> are quite high. One thing I didn't quite pick up is what happens if you try 
>>> to set document.domain when it's not settable. Will it silently pretend to 
>>> work, or will that also be a possible break point?
>>>
>>> I would be surprised if it didn't behave the same as setting an 
>>> arbitrary expando on `document` - we should be safe there.
>>>
>>
>> Almost. The error handling is mostly the same. But while a foreign 
>> attribute on document would return the new value, document.domain (when in 
>> an origin-keyed agent cluster) does not.
>>
>> So:
>>   document.foo = "bla"
>>   document.foo  // Returns "bla".
>>
>>   document.domain = "bla"  // Throws SecurityException.
>>
>>   // On a domain www.host.com, site-keyed agent cluster (current default)
>>   document.domain = "host.com"  // Succeeds.
>>   document.domain;  // returns "host.com".
>>
>>   // On a domain www.host.com, origin-keyed agent cluster (future 
>> default)
>>   document.domain = "host.com"  // Doesn't throw. Doesn't do anything 
>> else either.
>>   document.domain;  // Still returns www.host.com.
>>
>> Risks: Interoperability and Compatibility 
>>>
>>> * No interoperability risks. * 
>>> Compatibility risk exists, but is fairly small as document.domain is an 
>>> already deprecated feature. We’ve detailed UKM metrics in place and are 
>>> planning to reach out to top users as soon as we’ve LGTMs for the plan. 
>>>
>>> As Daniel mentioned, I think the compat risk should be considered to be 
>>> higher, despite this being deprecated for a long time.
>>>
>>
>> Yes, agreed.
>>
>>> Current usage of the document.domain: 0.05% 
>>>  of 
>>> page views rely upon document.domain to enable some cross-origin access 
>>> that wasn't otherwise possible. 0.24% 
>>>  of 
>>> page views block same-origin access because only one side sets 
>>> document.domain. Both counters can be found on 
>>> https://deprecate.it/#document-domain, too.
>>>
>>> (cool site, btw)
>>>
>>> We’ve reached out in advance to 4 of the top current users - TL;DR Most 
>>> of their use cases could be achieved already by different APIs e.g. 
>>> Audio/video autoplay in iframes by adding the ‘autoplay’ attribute, support 
>>> chat deployed across subdomains.
>>>
>>> Out of curiosity, did any of them mention what couldn't be achieved via 
>>> existing APIs?
>>>
>>
>> I checked back, and nothing particular came up.

Re: [blink-dev] Intent to Prototype: MediaRecorderErrorEvent API

[Domenic Denicola]

This seems like a problematic specification. They should just use
ErrorEvent, instead of creating a new class that is basically identical. I
have filed https://github.com/w3c/mediacapture-record/issues/211 and hope
we can go that route instead.

On Wed, Jan 12, 2022 at 11:59 AM Imranur Rahman  wrote:

> Contact emailsir.shi...@gmail.com
>
> ExplainerNone
>
> Specificationhttps://w3c.github.io/mediacapture-record/#errorevent-section
>
> Summary
>
> MediaRecorderErrorEvent is fired when Media Recording API faces an error.
> This API will enable developers to debug more conveniently when an
> exception occurs in Media Recording API. MediaRecorderErrorEvent will
> provide further details about the error with a DOMException object. BUG:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1250432 SPEC:
> https://w3c.github.io/mediacapture-record/#errorevent-section
>
>
> Blink componentBlink>MediaRecording
> 
>
> Motivation
>
> The main motivation is that currently Chromium fires a plain event,
> whereas if this feature is implemented the developers will have more
> knowledge about the occurred error in Media Recording API and debug
> conveniently.
>
>
> Initial public proposal
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>
> Other signals:
>
>
> Debuggability
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1250432
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5103987136135168
>
> 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/CAEq642EJPBbCQUGJ%2BuQAFrEi1HXZZAA%3D81x6-ZjdPYZ%3DJcWWqA%40mail.gmail.com
> 
> .
>

-- 
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/CAM0wra8OS3ffZcfONb-nEz0y3diWWaC3Xo%3Dh8W2ORK_hxQ6fEg%40mail.gmail.com.

[blink-dev] Intent to Prototype: MediaRecorderErrorEvent API

[Imranur Rahman]

Contact emailsir.shi...@gmail.com

ExplainerNone

Specificationhttps://w3c.github.io/mediacapture-record/#errorevent-section

Summary

MediaRecorderErrorEvent is fired when Media Recording API faces an error.
This API will enable developers to debug more conveniently when an
exception occurs in Media Recording API. MediaRecorderErrorEvent will
provide further details about the error with a DOMException object. BUG:
https://bugs.chromium.org/p/chromium/issues/detail?id=1250432 SPEC:
https://w3c.github.io/mediacapture-record/#errorevent-section


Blink componentBlink>MediaRecording


Motivation

The main motivation is that currently Chromium fires a plain event, whereas
if this feature is implemented the developers will have more knowledge
about the occurred error in Media Recording API and debug conveniently.


Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:


Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1250432

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5103987136135168

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/CAEq642EJPBbCQUGJ%2BuQAFrEi1HXZZAA%3D81x6-ZjdPYZ%3DJcWWqA%40mail.gmail.com.

Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

[Philip Jägenstedt]

Hi Anupam,

Could https://w3c.github.io/gamepad/extensions.html be a model to follow
here? I think it's important to write down (and test) what you intend to
ship in something that looks like a spec. If doing that in the EditingWG
doesn't seem tractable, then the WICG is also an option.

This seems like a fairly frustrating situation, but I hope it's clear what
to try next. If you do feel like you're stuck with what to do with the
spec, feel free to ask for advice here or off list.

Best regards,
Philip

On Thu, Jan 6, 2022 at 8:16 PM Anupam Snigdha  wrote:

> Re: “but I guess it did not actually include the pickling parts yet!”: It
> does include the pickling parts. See the unsanitized option in the
> ClipboardItemOptions dictionary, write unsanitized format, os specific
> custom map name and os specific custom name sections in the PR for more
> details.
>
>
>
> The part that is missing is the one that you mentioned “what to do for
> non-text data types being written to the clipboard. (Ctrl+F for "This is
> left to the implementation..." in
> https://github.com/w3c/editing/pull/383/files
> 
> .) ”
>
>
>
> “I think it's still important to write a spec somewhere, even if the
> EditingWG does not host it” – We will be merging this into the Editing
> repo, but it wouldn’t be part of the official clipboard API spec due to
> disagreement with Apple. Looks like FF is also interested
> 
> in standardizing the sanitization behavior because the legacy DataTransfer
> APIs behave the same in Chromium, FF, old Edge and IE, but since Apple
> opposed to these changes we couldn’t include it in the official clipboard
> API spec.
>
>
>
> *From:* Domenic Denicola 
> *Sent:* Thursday, January 6, 2022 11:01 AM
> *To:* Anupam Snigdha 
> *Cc:* Domenic Denicola ; Chris Harrelson <
> chris...@chromium.org>; Philip Jägenstedt ; Daniel
> Bratell ; Yoav Weiss ;
> blink-dev ; Alex Russell ;
> Abhishek Rathi ; svo...@gmail.com ;
> ajayra...@google.com ; Bo Cupp <
> pc...@microsoft.com>; m...@google.com ; Joshua Bell <
> jsb...@chromium.org>; Victor Costan ; Scott Low <
> sc...@microsoft.com>
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling
> for Async Clipboard API
>
>
>
>
>
>
>
> On Thu, Jan 6, 2022 at 1:24 PM Anupam Snigdha 
> wrote:
>
> Hi Domenic,
>
>
>
> I haven’t changed that part of the algorithm as I’m still working on the async
> API PR
> .
> Once that PR is completed, I’ll fill in all the missing steps in the async
> clipboard API algorithms that are applicable for pickling.
>
>
>
> Thanks for the clarification. It was confusing since your message said
> "here is the PR for the pickling API" but I guess it did not actually
> include the pickling parts yet!
>
>
>
> I have added all the algorithms needed to read/write custom formats and
> the unsanitized option that we introduced in the ClipboardItemOptions
> dictionary. Note that the sanitized copy part is still left up to the
> implementors as we couldn’t come to an agreement in EditingWG
> 
> .
>
>
>
> I think it's still important to write a spec somewhere, even if the
> EditingWG does not host it. See
> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines
> 
> for more on

Re: [blink-dev] Question on getting pixels from blink/renderer/modules/accessibility.

['Ramin Halavati' via blink-dev]

Thank you very much Philip. I will write a 1-pager on this discussion for
posteriority and will proceed with the inside blink approach.

Just as the concluding question, I have a draft CL on it (
crrev.com/c/3370381). Would you suggest that I take a (possibly simplified)
copy of the DataTransfer::NodeImage
in third_party/blink/renderer/modules/accessibility, or refactor the
existing code in DataTransfer to fit the existing and the new use case. I
prefer the latter as it is a very delicate and complex process. If you
agree with that, do you have any suggestions on the refactoring or I would
just go with it and ask you to take a look after?

Best,
Ramin

On Tue, Jan 11, 2022 at 6:58 PM Philip Rogers  wrote:

>
>
> On Tue, Jan 11, 2022 at 7:42 AM Ramin Halavati 
> wrote:
>
>> Thank you very much Philip,
>>
>> About the concern that a repaint based approach (similar to NodeImage)
>> will not have the backgrounds or other higher level effects, can we say
>> that on the other hand (specially since this function is explicitly
>> querying the image for a certain node) the full-page-paint+crop approach
>> also suffers from the possibility that the node maybe be partially covered
>> by another node, or being out of the screen's visible area (needing
>> scroll), or even being covered by a dialog box?
>>
>
> That's correct: the full-page-crop approach will include content on top of
> the target content, will not include the target if it is scrolled
> offscreen, etc.
>
>
>>
>> On Mon, Jan 10, 2022 at 8:29 PM Philip Rogers  wrote:
>>
>>>
>>>
>>> On Mon, Jan 10, 2022 at 6:51 AM Ramin Halavati 
>>> wrote:
>>>
 Thank you Philip.

 Since this accessibility support function is called for all renderer
 types (in ChromeOS including Arc++ and Ash), there would be a better
 consistency if we have the snapshotting code in the renderer. Therefore I
 am trying to avoid using the browser side ui::GrabViewSnapshot (as in
 DevTools), unless the alternative approach proves to be too complicated or
 unnecessarily heavy.

 I tried using DataTransfer::NodeImage in this draft CL
 , but my understanding is that since it
 triggers a repaint, we should make sure it is not in the middle of a
 lifecycle update to avoid conflicts. Is there a notification of a
 signal that tells when it's safe to request it?

>>>
>>> It is important that we do not introduce lifecycle violations but I
>>> think that may already be guaranteed from when the accessibility code runs.
>>> For example, AxObject::GetRelativeBounds cannot be called from within a
>>> lifecycle update either. You can probably just synchronously call the paint
>>> function you need.
>>>
>>>
 I assume it's the same for the SpoolSinglePage as it also redraws the
 image. And performance wise, can we say that as this approach triggers a
 repaint, it's heavier than the browser based snapshotting (using
 ui::GrabViewSnapshot), as the latter is using the already painted output
 and does not require a repaint?

>>>
>>> The paint code in NodeImage is really just a walk of layout
>>> datastructures and isn't more expensive than things like layout, style, etc
>>> (i.e., it's O(|layout|)). Doing this for each object would be wildly
>>> inefficient though.
>>>
>>> Expanding on the thing about this being an ambiguous problem:
>>> data:text/html,hello world
>>> The drag image for the div will only contain white and transparent
>>> pixels, and will not be blurred. If you want the purple background too,
>>> you'll want to do the full-page-paint+crop approach.
>>>
>>>

 Best,
 Ramin

 On Fri, Jan 7, 2022 at 11:06 PM Philip Rogers  wrote:

> This is a deceptively difficult problem in general. Our paint system
> uses the CSS definition of paint order which starts painting at stacking
> contexts and it is challenging to exclude non-stacked siblings of a
> non-stacked target element. Some other complications are whether ancestor
> effects/clips should be applied, and whether content behind the target
> should be included.
>
> DataTransfer::NodeImage is an attempt at this. Another option is to
> get the entire page painted (examples: devtools uses
> PageHandler::CaptureScreenshot and printing uses SpoolSinglePage), then
> crop it to the target element.
>
> On Fri, Jan 7, 2022 at 7:01 AM 'Ramin Halavati' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi,
>>
>> I am trying to find a way to get pixels for any general node in
>> *third_party/blink/renderer/modules/accessibility. *We already have
>> AXNodeObject::ImageDataUrl
>> 

Re: [blink-dev] Intent to Ship: CORS non-wildcard request-header

[Yutaka Hirano]

Hi Yoav,

Thank you for the suggestions. I'll try to add UKM.

> One other question that came up: Is the usage related to developers
adding the "Authorization" header on their own, or is it something the
browser sends under certain circumstances? (e.g. when receiving 401
responses with "WWW-Autenticate" headers)

This is only for authorization headers set by scripts (via fetch() and
XHR). Authorization headers the browser attaches are out of scope.

On Thu, Jan 6, 2022 at 2:15 AM Yoav Weiss  wrote:

> Hey Yutaka!
>
> We discussed this at the API owners meeting today (Daniel, Chris, Alex,
> MikeT and myself).
> It seems like the risk here is too high to remove support as is, and a
> reasonable next step may be to add the metric to UKM and get a more
> detailed view of which sites are using it and how. That would enable us to
> better assess breakage, and reach out to those sites to reduce current
> usage until potential breakage reaches acceptable levels.
>
> One other question that came up: Is the usage related to developers adding
> the "Authorization" header on their own, or is it something the browser
> sends under certain circumstances? (e.g. when receiving 401 responses with
> "WWW-Autenticate" headers)
> Would renaming the headers used in such authentication protocols be a
> useful alternative to consider? I'm guessing that doing that would require
> server changes as well, so won't necessarily help with cases of existing
> content, but may help to move newer auth flows to make safer CORS choices.
>
> Cheers :)
> Yoav
>
> On Thursday, December 9, 2021 at 12:17:40 PM UTC+1 Yutaka Hirano wrote:
>
>> We've been showing a deprecation message since 94
>> .
>> Sadly the deprecation message hasn't decreased the usage so far.
>>
>> On Thu, Dec 9, 2021 at 1:52 AM Mike West  wrote:
>>
>>> From my perspective, it's a bit worrying that you found user-visible
>>> breakage in a random sampling of the otherwise small number of sites that
>>> fall into this category. As Yoav suggested, there's some additional
>>> likelihood that we're not seeing some breakage that requires sign-in. It
>>> might be worthwhile to raise a deprecation warning for this behavior, and
>>> remove it after giving developers some time to adjust, perhaps with an
>>> enterprise policy for good measure. I'd be happy with a 3-release timeline,
>>> with removal thereafter. That might drive the usage down to the point where
>>> we can reasonably remove it. If it doesn't, we might need to do some more
>>> research (wiring this counter up to UKM, for instance) to see if we can
>>> track down more clear sources of potential breakage.
>>>
>>> -mike
>>>
>>> On Thursday, December 2, 2021 at 6:56:40 AM UTC+1 Yutaka Hirano wrote:
>>>
 On Thu, Dec 2, 2021 at 12:29 AM Yoav Weiss 
 wrote:

>
>
> On Wed, Dec 1, 2021 at 4:00 PM Yutaka Hirano 
> wrote:
>
>> Sorry for the delay!
>>
>> I checked 10 sites. I saw console errors in three sites among them:
>>  1. https://cchatty.com/
>>  2. https://techrxiv.org/
>>  3. https://bodyshake.com/
>>
>> I only see a visible breakage in 1 (cards in the main panel are
>> invisible). On other sites I don't see any visible differences.
>> Please note that this feature is related to authorization so it is
>> likely to break things when signing in.
>>
>
> So it's possible that the breakage only occurs for logged in users,
> and is not something you'd be able to see when spot checking their 
> homepage?
>
>
 Yeah, I think so.



>
>>
>> On Wed, Dec 1, 2021 at 8:11 PM Yoav Weiss 
>> wrote:
>>
>>> Friendly ping on Chris' question
>>>
>>> On Thursday, November 4, 2021 at 8:31:36 PM UTC+1 Chris Harrelson
>>> wrote:
>>>
 Would it be feasible to get a random list of 10-20 sites that hit
 the use counter and see if they are broken badly by this feature?

 On Thu, Nov 4, 2021 at 4:54 AM Yutaka Hirano 
 wrote:

> (friendly ping)
>
> On Mon, Nov 1, 2021 at 1:57 PM Yutaka Hirano 
> wrote:
>
>> Thank you for the feedback.
>>
>> Do you have concrete steps for the investigation in your mind?
>>
>> On Fri, Oct 29, 2021 at 4:30 AM Mike West 
>> wrote:
>>
>>> I think it's reasonable for us to dig into the data a little bit
>>> to determine whether the 0.04% number quoted above will result in
>>> user-facing breakage. Yutaka, is that something you'd be willing to 
>>> dig
>>> into?
>>>
>>> The direction seems philosophically correct to me, so I'd like
>>> to see it ship, but I'd also like to make sure we're not making the 
>>> web
>>> worse for users by doing so.
>>>
>>> -mik

Re: [blink-dev] Intent to Ship: Allow infinity, -infinity and NaN in CSS calc()

[Christian Biesinger]

On Tue, Jan 11, 2022 at 10:34 PM Emilio Cobos Álvarez
 wrote:
>
> Hi Seokho,
>
> Curious, how do I enable this in Canary? I tried but the experimental
> features doesn't seem to enable this (unless I'm holding it wrong).

To answer this question -- you can enable individual runtime-enabled
features using --enable-blink-features=CSSCalcInfinityAndNaN

Christian

-- 
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/CAPTJ0XE1v8_Sr_%3DM2ReHsNb3jZULtFrPgqUbQOzVPXOUgVtk8g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: HTMLInputElement showPicker()

['François Beaufort 🇫🇷' via blink-dev]

On Wed, Dec 15, 2021 at 5:59 PM Alex Russell 
wrote:

> LGTM3
>
> On Wednesday, December 15, 2021 at 7:51:30 AM UTC-8 Yoav Weiss wrote:
>
>> LGTM2
>>
>> On Wednesday, December 15, 2021 at 4:18:50 PM UTC+1 Mike West wrote:
>>
>>> LGTM1.
>>>
>>> Given that this codifies existing Chrome behavior in a way that it seems
>>> like other vendors can get on board with, I'm supportive of shipping this
>>> more standardized mechanism for showing native UX. I do wonder what we're
>>> going to do with `click()` in the long term. Is there a deprecation plan
>>> for that behavior, since it seems unlikely to become interoperable
>>> otherwise?
>>>
>>>
@Domenic Denicola  outlined a plan for showPicker and
click() at https://github.com/whatwg/html/issues/6909#issuecomment-897097048

In the meantime, I've just added a use counter for HTMLInputElement click()
so that we can track how much the web platform relies on this feature. See
https://chromium-review.googlesource.com/c/chromium/src/+/3358063


-mike
>>>
>>>
>>> On Tue, Dec 14, 2021 at 4:03 PM 'Joe Medley' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 You already answered that in the intent. I'm blind.

 On Monday, December 13, 2021 at 10:54:32 AM UTC-8 Joe Medley wrote:

> When are you hoping to ship this?
> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Dec 13, 2021 at 12:58 AM 'François Beaufort 🇫🇷' via
> blink-dev  wrote:
>
>> Contact emails
>>
>> fbea...@google.com
>>
>> Explainer
>>
>> https://github.com/whatwg/html/pull/7319
>>
>> Specification
>>
>> https://html.spec.whatwg.org/multipage/input.html#dom-input-showpicker
>>
>> Summary
>>
>> The HTMLInputElement showPicker() method allows web developers to
>> programmatically show a browser picker for input elements (temporal, 
>> color,
>> file, and those with suggestions like datalist or autofill).
>>
>> Blink component
>>
>> Blink>Forms
>> 
>>
>> Motivation
>>
>> Developers have been asking for years for a way to programmatically
>> open a browser date picker. See
>> https://www.google.com/search?q=programmatically+open+date+picker+site:stackoverflow.com
>> 
>>
>> Because of that, they had to rely on custom widget libraries and CSS
>> hacks for specific browsers.
>>
>> This is currently possible in some browsers, for some controls, via
>> the click() method. However this is not interoperable (
>> https://github.com/whatwg/html/issues/6909#issuecomment-897097048)
>> and considered a bad idea (
>> https://github.com/whatwg/html/issues/3232#issuecomment-345279014).
>> Providing showPicker() gives developers a supported alternative to 
>> click(),
>> and will allow us to align Chromium's click() behavior with the
>> specification and other browsers in a future Intent to Ship.
>>
>> Initial public proposal
>>
>> https://github.com/whatwg/html/issues/6909
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/688
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> For interoperability: This feature was developed in collaboration
>> with Gecko engineers, who are positive. It also will help with improving
>> click() interoperability in the future, which is currently messy (
>> https://github.com/whatwg/html/issues/6909#issuecomment-897097048).
>>
>> For compatibility: this feature is specified and designed to give
>> browsers flexibility in whether they display a picker, or how they 
>> display
>> it. Developers cannot observe either of these things (except for file
>> pickers, which fire certain events), so we will not be constrained by any
>> JavaScript-observable behavior if we need to make future changes to form
>> control UIs.
>>
>> Gecko: Positive -
>> https://github.com/whatwg/html/pull/7319#issuecomment-988837778
>>
>> WebKit: No signal -
>> https://lists.webkit.org/pipermail/webkit-dev/2021-December/032071.html
>>
>> Web developers: Positive -
>> https://twitter.com/quicksave2k/status/1420320560345661440 (6
>> Retweets and 29 Likes) - https://github.com/whatwg/html/issues/6909
>> (9 👍  and 5 ❤️) show that developers like this particular solution. Plus
>> the evidence of developer interest in the use case, per the Motivation
>> section above.
>>
>>
>> Debuggability
>>
>> No specific DevTools changes are required. This feature is treated
>> like any other JS metho