Re: [blink-dev] Re: Intent to Ship: Fenced Frames

[Joshua Bell]

Just a quick note on spec maturity:  as spec mentor, I did a thorough
review of the spec text, and noted many issues - all small - which have
been addressed. As the feature introduces a privacy boundary between two
documents with very sensitive one-way control, it is non-trivial but the
design is well thought out and the exposed API makes sense for the use
case. The primarily challenge with maintaining the spec going forward is
that it is a series of patches on top of [HTML] and a handful of other
specs, but these patches are extremely clearly written and the rationale is
easy to understand.

On Wed, Jun 21, 2023 at 8:57 AM Mike Taylor  wrote:

> LGTM3
> On 6/21/23 11:53 AM, Rick Byers wrote:
>
> LGTM2
>
> On Wed, Jun 21, 2023 at 11:46 AM Chris Harrelson 
> wrote:
>
>> LGTM1
>>
>> Thank you for thoroughly working through all the design and specification
>> steps for this feature. Glad to see some positive signals from the TAG
>> about the fundamental design in particular.
>>
>> I agree that Alex's comments are good to answer and investigate for
>> future work, but also they aren't blocking this intent. (Confirmed this
>> interpretation with Alex.)
>>
>> On Wed, Jun 21, 2023 at 8:42 AM Alex Russell 
>> wrote:
>>
>>> Hey all,
>>>
>>> I'm not going to weigh in on if this should ship right now, but I want
>>> to express some disappointment that this design seems to be launching
>>> without a way to load from a bundle and a flag for removing the ability to
>>> load from the network. We have a lot of use-cases that would benefit from a
>>> version of  that was more capable and generic, rather than
>>> being narrowly targeted at an ads use-case.
>>>
>>> What's the prognosis for fixing those deficiencies in near-future work?
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Tuesday, June 20, 2023 at 5:07:07 AM UTC-7 Shivani Sharma wrote:
>>>
 Contact emails

 shivani...@chromium.org , d...@chromium.org, jkar...@chromium.org



 Explainer

 https://github.com/WICG/fenced-frame/tree/master/explainer

 Spec

 https://wicg.github.io/fenced-frame/

 Summary

 In a web that has its cookies and storage partitioned by top-frame
 sites, there are occasions (such as Interest group based advertising
  or Consistent A/B experiments
 across sites
 )
 when it would be useful to display content based on inputs from different
 partitions on the same page. For such use cases, it would be ideal from a
 privacy perspective, if the documents that contain data from different
 partitions are isolated from each other such that they're visually composed
 on the page, but unable to communicate with each other. Iframes do not suit
 this purpose since they have several communication channels with their
 embedding frame (e.g., postMessage, URLs, size attribute, etc.). We propose
 fenced frames, a new element to embed documents on a page, that explicitly
 prevents communication between the embedder and the frame.


 At the time of this I2S, fenced frames can be created and navigated
 using the `FencedFrameConfig` object returned from the following APIs:

-

Protected Audience API runAdAuction() (code snippet

 
)
-

Shared Storage API selectUrl() (code snippet

 
)

 (For future use cases of fenced frames, separate I2S would be sent.)

 Blink component

 Blink>FencedFrames
 

 TAG reviews and status

 early design review
 
 (status: complete),

 specification review
  (status: pending)

 Link to Origin Trial feedback summary

 Fenced frames are part of the unified Privacy Sandbox OT and are an
 integral part of the privacy design of “Protected Audience” and “Shared
 Storage” APIs. For easier adoption, these consumer APIs don’t currently
 enforce the use of fenced frames, but we have had multiple testers

Re: [blink-dev] Intent to Experiment: EditContext API

[Joshua Bell]

I'm excited to see this!

On Mon, Jun 12, 2023 at 4:13 PM 'Daniel Clark' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> sni...@microsoft.com, shih...@microsoft.com, bemat...@microsoft.com,
> dan...@microsoft.com
>
>
> Explainer
>
> https://github.com/w3c/edit-context/blob/gh-pages/explainer.md
>
>
> Specification
>
> https://w3c.github.io/edit-context
>
>
> Design docs
>
>
> https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md
>
>
> Summary
>
> The EditContext API simplifies the process of integrating a web app with
> advanced text input methods such as VK shape-writing, Handwriting panels,
> speech recognition, IME Compositions etc., improves accessibility and
> performance, and unlocks new capabilities for web-based editors.
>
>
>
>
> Blink component
>
> Blink>Editing
> 
>
>
> Search tags
>
> editing , contenteditable
> , input
> , rawinput
> , ime
> 
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/416
>
>
> TAG review status
>
> Pending
>
>
> Risks
>
>
>
>
> Interoperability and Compatibility
>
> There are no known interop or compat risks.
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Strongly positive Positive feedback from Word online,
> Adobe and Figma, Google Docs
>
> *Other signals*:
>
>
> Activation
>
> Developers interested in this feature will typically have their own
> polyfill for text input using hidden textarea or contenteditable elements.
> Feature detecting and using new API to avoid side effects of previous
> approaches is intended to be easily adoptable.
>
>
>
>
> WebView application risks
>
> None
>
>
>
>
> Goals for experimentation
>
> We are looking for feedback on the developer ergonomics of using the API
> and for confirmation that it meets the needs of production web apps for
> various input modes. This is a complex API, and different developers are
> expected to use it in different ways. For example, some partners plan to
> construct the view of their editable region in the subtree of the
> EditContext-associated element, while other partners plan to keep the
> EditContext-associated element off-screen while using the EditContext APIs
> to set the bounds of the editable region.
>
>
>
> We want to ensure that our design enables all these scenarios and is
> robust given the wide field of IMEs utilized by different users, which may
> have subtly different behaviors and event timings.
>
>
> Ongoing technical constraints
>
> None
>
>
>
>
> Debuggability
>
> Existing DevTools functionality should suffice to debug EditContext.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
>
Although in the template this is phrased as a yes/no question, can you say
more about the WPT coverage and limitations?


>
> Flag name
>
> --enable-blink-features=EditContext
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=999184
>
>
> Estimated milestones
>
> No milestones specified
>
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5041440373604352
>
>
> Links to previous Intent discussions
>
> I2I:
> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/OHqvPx9mFww/m/1za_qdEHDwAJ
>
> 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/SN6PR00MB0448C960D827BFAFE2FD1F2CC554A%40SN6PR00MB0448.namprd00.prod.outlook.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/CAD649j6nOERTrXQyNH6EsQ-GcKueiCgVxXBnYMJPa9CppymQjQ%40mail.gmail.com.

Re: [blink-dev] RE: Intent to Prototype: Delayed clipboard rendering

[Joshua Bell]

Hey folks! This is very exciting to see.

I notice the linked explainer is marked Archived, and links to itself as
the current version? The attached design doc is helpful, but *unhelpfully*
forbids copy/paste. Can you fix that?

The explainer calls out that there's no API change, but the design doc's
example shows the ClipboardItem consuming what looks like a promise that
resolves to a function... which doesn't seem to be what's intended. What's
the best way for other Chromium folks to help you iterate on the explainer
and API design, and provide feedback on the design doc?

Again, this is awesome to see - I've definitely heard requests for this
functionality from many partners.

On Fri, Mar 3, 2023 at 3:48 PM 'Ana Sollano Kim' via blink-dev <
blink-dev@chromium.org> wrote:

> Sending some clarifications.   TAG review
>
> Performance improvement. No change in Web APIs.
>
>
> TAG review status
>
> Not applicable
>
>
> Interoperability and Compatibility
>
> Chromium is the first browser to support delayed clipboard rendering.
> Firefox and Safari have expressed no concerns about the concept.
>
>
>
> *Gecko*: Neutral (
> https://github.com/mozilla/standards-positions/issues/758) Expressed no
> concerns, conversation:
> https://github.com/w3c/editing/issues/417#issuecomment-1452770119
>
> *WebKit*: Positive (
> https://github.com/WebKit/standards-positions/issues/144) Expressed no
> concerns, conversation:
> https://github.com/w3c/editing/issues/417#issuecomment-1452770119
>
> *Web developers*: Positive Our partners have shown interest to leverage
> delayed clipboard rendering along with the Clipboard Async API's custom
> formats.
>
> 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?*
>
> No.
>
>
> Design Doc
>
>
> https://docs.google.com/document/d/1OIyzmilYbV7xc6JvNt73ELQX_DyiL-b3tkFZ3OGBrt0/edit?usp=sharing
>
>
>
> *From:* Ana Sollano Kim
> *Sent:* Friday, March 3, 2023 1:22 PM
> *To:* blink-dev@chromium.org; Anupam Snigdha ;
> Sanket Joshi (EDGE) ; 'est...@chromium.org' <
> est...@chromium.org>; 'etiennen...@chromium.org' ;
> 'asu...@chromium.org' ; 'dch...@chromium.org' <
> dch...@chromium.org>; 'a...@chromium.org' 
> *Subject:* Intent to Prototype: Delayed clipboard rendering
>
>
> Contact emails
>
> ansol...@microsoft.com, sni...@microsoft.com, sa...@microsoft.com
>
> Explainer
>
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DelayedClipboard/DelayedClipboardRenderingExplainer.md
>
> Specification
>
> https://w3c.github.io/clipboard-apis
>
> Summary
>
> Delays the generation of the clipboard payload until it is needed by the
> target applications. Delayed clipboard rendering leverages the existing
> Async Clipboard API to allow web applications to improve performance when
> exchanging large data payloads by only producing the clipboard payload once
> a target application attempt to access it.
>
>
>
> Blink component
>
> Blink>DataTransfer
> 
>
> Motivation
>
> Source applications typically don’t know where the user intends to paste
> the content at the time of copy, so web applications may produce several
> formats when writing to the clipboard to prepare for many possible target
> applications. The generation of one or more representations may take enough
> time that it is noticeable to the user, but it is unlikely that the target
> application will need all produced representations.
>
>
>
> Initial public proposal
>
> https://github.com/w3c/editing/issues/417
>
> TAG review
>
>
>
> TAG review status
>
> Pending
>
> Risks
>
>
>
> Interoperability and Compatibility
>
> Chromium is the first browser to support delayed clipboard rendering.
> Firefox and Safari have expressed no concerns about the concept.
>
>
>
> *Gecko*: No signal (
> https://github.com/w3c/editing/issues/417#issuecomment-1452770119)
> Expressed no concerns.
>
> *WebKit*: No signal (
> https://github.com/w3c/editing/issues/417#issuecomment-1452770119)
> Expressed no concerns.
>
> *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?*
>
>
>
> Debuggability
>
> The Async Clipboard API have tooling support as described in the DevTools
> support checklist.
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
> Flag name
>
> TBD
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1408850
>
> Estimated milestones
>
> No milestones specified
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5124936324087808
>
> This intent message was gene

Re: [blink-dev] Re: Intent to Ship: WebGLContextEvent on Web Workers

[Joshua Bell]

I dug in a bit. Looks like the webgl1 and webgl2 IDLs are indeed extracted
by the workflow and placed in
https://github.com/web-platform-tests/wpt/tree/master/interfaces (yay!) and
the WebXR tests even reference the webgl1 IDLs but there's no idlharness
test that actually exercises them. (boo!)

A pretty minimal idlharness test should (...) automagically verify exposure
of interfaces in the appropriate global contexts (e.g. you'd have a
window.js and worker.js version); that'd be good to add for WebGL - it
would have caught this issue. Slightly more elaborate tests mint various
objects so the properties can be inspected. You can find examples looking
for files named "idlharness.https.window.js" etc in the various Web
Platform Test (WPT) dirs: https://github.com/web-platform-tests/wpt

Attention blink-dev lurkers! Adding WPTs is a great way to get started
contributing to the web platform, if anyone out there is looking to help
out! Plenty of mentors around here to help folks out! Ken and I can
probably review.

On Mon, Feb 13, 2023 at 9:00 PM Ken Russell  wrote:

> Sorry, not sure. The living WebGL specs are hosted at:
>
> https://registry.khronos.org/webgl/specs/latest/1.0/
> https://registry.khronos.org/webgl/specs/latest/2.0/
>
> The IDL is actually auto-extracted from the spec so should be easy to
> ingest and validate against Blink's.
>
> One other thing to consider is that Blink's IDL might not be exactly
> identical to the spec's - for example, Blink uses several extended and
> non-standard Web IDL attributes to optimize the calling convention of
> certain entry points. I also vaguely recall some issues with overloads that
> were legal in Web IDL but needed some hackery to build properly in Blink,
> but not sure about this.
>
>
Re: Blink IDL - the good news is that the idlharness WPTs don't look at
Blink's IDL at all - they consume the spec's IDL and try to verify that the
execution environment they're running in is providing objects that behave
as in the IDL, as much as possible. It's not perfect - argument and return
types can't be determined, for example - but it can catch many things.
Hackery e.g. using overloads to simulate unions shouldn't be an issue,
either because neither can be tested properly or because if we get the
overloads right they're indistinguishable from the unions, as intended.

But anyway, "simple" things like interface exposure should just work, since
they'll compare the spec IDL and assert that the global contains an
appropriately named property.


> -Ken
>
>
>
> On Mon, Feb 13, 2023 at 10:18 AM Joshua Bell  wrote:
>
>> Super low priority question:
>>
>> We've got WPTs and tooling that slurps Web IDL from specs and validates
>> it against implementations which in theory should have caught this. This is
>> a fairly fragile process (requires spec to be just right, jobs to be
>> configured, tests to exist, integration bots to successfully run it,
>> failures to get bugs filed, humans to triage, etc) so I'm not surprised
>> this was missed, but do you happen to know where in the pipeline we dropped
>> the ball in this case?
>>
>>
>>
>>
>> On Sun, Feb 12, 2023 at 9:35 AM Kenneth Russell  wrote:
>>
>>> Sorry for the delay replying...this email didn't show up in my Inbox nor
>>> Spam folder.
>>>
>>> The other browsers handle this in the same way. Firefox has supported
>>> WebGL on web workers for some time, and Safari had exactly the same IDL bug
>>> which they just fixed.
>>>
>>> -Ken
>>>
>>>
>>> On Wednesday, February 8, 2023 at 9:35:47 AM UTC-7 slightlyoff via
>>> Chromestatus wrote:
>>>
>>>> LGTM1 Do we know if other browsers that support offscreen canvas
>>>> (Safari TP, e.g.) handle this the same way? Or are we the first to ship?
>>>>
>>> --
>>> 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/1da41865-85f7-449c-89e2-d000bf509d86n%40chromium.org
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1da41865-85f7-449c-89e2-d000bf509d86n%40chromium.org?utm_medium=email&utm_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/CAD649j6E0Zfo4qZ2vg8TGxeqVYMKWwSaqsUwgg6UpbqjA76ZHQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WebGLContextEvent on Web Workers

[Joshua Bell]

Super low priority question:

We've got WPTs and tooling that slurps Web IDL from specs and validates it
against implementations which in theory should have caught this. This is a
fairly fragile process (requires spec to be just right, jobs to be
configured, tests to exist, integration bots to successfully run it,
failures to get bugs filed, humans to triage, etc) so I'm not surprised
this was missed, but do you happen to know where in the pipeline we dropped
the ball in this case?




On Sun, Feb 12, 2023 at 9:35 AM Kenneth Russell  wrote:

> Sorry for the delay replying...this email didn't show up in my Inbox nor
> Spam folder.
>
> The other browsers handle this in the same way. Firefox has supported
> WebGL on web workers for some time, and Safari had exactly the same IDL bug
> which they just fixed.
>
> -Ken
>
>
> On Wednesday, February 8, 2023 at 9:35:47 AM UTC-7 slightlyoff via
> Chromestatus wrote:
>
>> LGTM1 Do we know if other browsers that support offscreen canvas (Safari
>> TP, e.g.) handle this the same way? Or are we the first to ship?
>>
> --
> 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/1da41865-85f7-449c-89e2-d000bf509d86n%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/CAD649j4yUbH0aCd6Ju0NYVoQ%3D1Rm1oqx_LAHdraOewZq1Nk%3DrQ%40mail.gmail.com.

Re: [blink-dev] Intent to Remove: window.webkitStorageInfo

[Joshua Bell]

NOT shipping in 106.

Since this is not a security-motivated removal (there are other APIs that
provide the same data), despite the usage numbers being extremely low we
are holding until we've made our best effort to reach out to partners using
Chrome in scenarios where we may not have usage metrics, just to avoid
surprises.

ayui@ will update the thread when we have a new target milestone.

On Tue, Aug 23, 2022 at 11:20 AM jmedley via Chromestatus <
admin+jmed...@cr-status.appspotmail.com> wrote:

> Is this shipping in 106?
>
> --
> 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/faac1205e6ec9e4f%40google.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/CAD649j4G4bUz46R8oewForQX8-183BzwyXOVSKJY470uGQ-%2B-Q%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Writable directory prompts for the File System Access API

[Joshua Bell]

Since this is an incremental addition to the existing FSA API, my guess is
that the positions there sufficient here:

Gecko: https://mozilla.github.io/standards-positions/#native-file-system
Webkit:
https://lists.webkit.org/pipermail/webkit-dev/2020-August/031362.html

These two engines give a Negative signal. I would not expect they would
comment further on this incremental addition.



On Wed, Jun 15, 2022 at 8:06 AM 'Austin Sullivan' via blink-dev <
blink-dev@chromium.org> wrote:

> No, I did not realize this was required? showDirectoryPicker() is
> currently only implemented for Chromium browsers
>
> On Wed, Jun 15, 2022 at 7:55 AM Yoav Weiss  wrote:
>
>>
>>
>> On Monday, June 13, 2022 at 1:58:43 PM UTC+2 Austin Sullivan wrote:
>>
>>> Contact emailsasu...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://github.com/WICG/file-system-access/pull/300
>>>
>>> Summary
>>>
>>> Allow returning a directory with both read and write permissions in a
>>> single prompt for the File System Access API. Currently
>>> showDirectoryPicker() always returns a read-only directory (after showing a
>>> read access prompt), requiring a second permission prompt to get write
>>> access. This double-prompt is a poor user experience and contributes to
>>> confusion and permission fatigue among users.
>>>
>>>
>>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>>> specified as "read" or "readwrite".
>>>
>>>
>>> Blink componentBlink>Storage>FileSystem
>>> 
>>>
>>> TAG reviewWe did not seek a TAG review given the small scope of this
>>> feature. This launch does not add any new capabilities, but merely provides
>>> the browser with enough information to combine two permission prompts into
>>> one.
>>>
>>
We have filed TAG design review requests for incremental additions to the
FSA API (examples: 1 ,
2 , 3
) - I think it's worth
doing here as well, although I expect support since it's following existing
patterns (using an enum value in an options dictionary, with a
reasonable/safe default).



>
>>> TAG review statusN/A
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>
>> Have you asked for signals? https://bit.ly/blink-signals
>>
>>
>>>
>>> *Web developers*: Strongly positive (
>>> https://github.com/WICG/file-system-access/issues/89)
>>>
>>> *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?
>>>
>>> No
>>>
>>>
>>>
>>> Debuggability
>>>
>>> N/A
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?No - The File System
>>> Access API is not supported on Android
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1115632
>>>
>>> Launch bughttps://crbug.com/1213159
>>>
>>> Estimated milestones
>>>
>>> 105
>>>
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6383970247770112
>>>
>>> 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/CADs-7rEsYumZp%3Dd9VuzMixOq5xB7kD0HxrQ2QwYvLM_K%2B7LaLw%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/CAD649j5j_1PREcHpQVy3YE8MUMxKEe%2B9rNNUVgX271D_WozqSw%40

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

[Joshua Bell]

Thanks for the pings, Marcos. I'll try and have an update for you in the
next week.

On Thu, May 26, 2022 at 8:07 AM Marcos Caceres  wrote:

> 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
> 
> .
>
 --
> 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
> 
> .
>

-- 
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/CAD649j4eHzWf6RS-yQr%3D3X%3Ds72zF9j%3Duu8XUJsD0YT6ykgnhzA%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Local Fonts Access API

['Joshua Bell' via blink-dev]

FYI, non-normative note added. I also followed up on the questions in the
Moz standards position thread, added a few more notes to the spec as well.

On Wed, Apr 27, 2022 at 9:01 AM Alex Russell 
wrote:

> A non-normative note in the spec sounds good. Wouldn't want to block
> shipping on it.
>
> On Wednesday, April 27, 2022 at 2:05:53 AM UTC-7 Yoav Weiss wrote:
>
>> If we're going with exposing byte-by-byte representation of the fonts on
>> the user's filesystem, we should make that slightly more explicit. Maybe
>> add a note to
>> https://wicg.github.io/local-font-access/#font-representation-data-bytes
>> clarifying that point?
>>
>> I *think* that lack of normalization should resolve the issues Anne was
>> concerned about in https://github.com/WICG/local-font-access/issues/20,
>> where different normalization algorithms result in compatibility issues. I
>> also *think* it should resolve Tess' concerns RE user assumptions of the
>> fonts being Open-Type. Can you clarify those points with them?
>>
>> On Monday, April 25, 2022 at 6:12:00 PM UTC+2 Alex Russell wrote:
>>
>>> Normalisation isn't usually a goal for users that want the actual bytes
>>> of the local font in order to do the rendering themselves and can be an
>>> active non-goal given the ways that folks want to do custom grouping,
>>> enumeration, and rendering. Partners have consistently asked us not to
>>> remove information and I've never heard of a request for normalisation from
>>> a partner.
>>>
>>> This is in line with not adding OTS sanitisation for these files  (we
>>> don't need to when the OS rendering pipeline isn't at potential risk), and
>>> highlights the way that the current design is isomorphic with local file
>>> access.
>>>
>>> I've LGTM'd it in the tool as a result.
>>>
>>> Thanks to everyone at Google for continuing to push this forward.
>>>
>>> Best Regards,
>>>
>>> Alex
>>>
>>> On Thursday, April 21, 2022 at 9:46:15 AM UTC-7 Joshua Bell wrote:
>>>
>>>> On Wed, Apr 20, 2022 at 4:21 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 13, 2022 at 6:46 PM Joshua Bell  wrote:
>>>>>
>>>>>> On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss 
>>>>>> wrote:
>>>>>>
>>>>>>> Also, any learnings/feedback from the Origin Trial?
>>>>>>>
>>>>>>>
>>>>>> Not distinct from the dev trial (i.e. developers trying the API
>>>>>> behind a flag). There was a feature request for additional metadata which
>>>>>> was implemented, then the request was withdrawn so that code was backed
>>>>>> out. Other requests are marked as "enhancements" in the issue tracker, 
>>>>>> e.g.
>>>>>> font modification timestamps.
>>>>>>
>>>>>>
>>>>>>> On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote:
>>>>>>>
>>>>>>>> On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote:
>>>>>>>>
>>>>>>>>> Contact emails
>>>>>>>>>
>>>>>>>>> ds...@chromium.org, jsb...@chromium.org
>>>>>>>>>
>>>>>>>>> Explainer
>>>>>>>>>
>>>>>>>>> https://github.com/WICG/local-font-access
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>>
>>>>>>>>> https://wicg.github.io/local-font-access/
>>>>>>>>>
>>>>>>>>> Design docsDesign Doc: https://bit.ly/2HWBOLi
>>>>>>>>> <https://chromestatus.com/admin/features/launch/6234451761692672/Design%20Doc:%20https://bit.ly/2HWBOLi>
>>>>>>>>>
>>>>>>>>> Blog: https://web.dev/local-fonts/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Summary
>>>>>>>>>
>>>>>>>>> Gives web applications the ability to enumerate local fonts and
>>>>>>>>> some metadata about each. Today, no API exists to provide a list of 
>>>>>>>>> local
>>>>>

[blink-dev] Re: Intent to Ship: Local Fonts Access API

['Joshua Bell' via blink-dev]

On Wed, Apr 20, 2022 at 4:21 AM Yoav Weiss  wrote:

>
>
> On Wed, Apr 13, 2022 at 6:46 PM Joshua Bell  wrote:
>
>> On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss 
>> wrote:
>>
>>> Also, any learnings/feedback from the Origin Trial?
>>>
>>>
>> Not distinct from the dev trial (i.e. developers trying the API behind a
>> flag). There was a feature request for additional metadata which was
>> implemented, then the request was withdrawn so that code was backed out.
>> Other requests are marked as "enhancements" in the issue tracker, e.g. font
>> modification timestamps.
>>
>>
>>> On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote:
>>>
>>>> On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote:
>>>>
>>>>> Contact emails
>>>>>
>>>>> ds...@chromium.org, jsb...@chromium.org
>>>>>
>>>>> Explainer
>>>>>
>>>>> https://github.com/WICG/local-font-access
>>>>>
>>>>> Specification
>>>>>
>>>>> https://wicg.github.io/local-font-access/
>>>>>
>>>>> Design docsDesign Doc: https://bit.ly/2HWBOLi
>>>>> <https://chromestatus.com/admin/features/launch/6234451761692672/Design%20Doc:%20https://bit.ly/2HWBOLi>
>>>>>
>>>>> Blog: https://web.dev/local-fonts/
>>>>>
>>>>>
>>>>> Summary
>>>>>
>>>>> Gives web applications the ability to enumerate local fonts and some
>>>>> metadata about each. Today, no API exists to provide a list of local fonts
>>>>> to web applications.
>>>>>
>>>>> Also gives web applications access to the font data as a binary blob,
>>>>> allowing those fonts to be rendered within their applications using custom
>>>>> text stacks.
>>>>>
>>>>> Blink component
>>>>>
>>>>> Blink>Fonts
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts>
>>>>>
>>>>> TAG review
>>>>>
>>>>> https://github.com/w3ctag/design-reviews/issues/400
>>>>>
>>>>> TAG review status
>>>>>
>>>>> Pending
>>>>>
>>>>> RisksInteroperability and Compatibility
>>>>>
>>>>> This API has been designed to support feature detection to allow
>>>>> applications to gracefully degrade based on the capabilities different 
>>>>> user
>>>>> agents offer.
>>>>>
>>>>> We expect developers using this API to design their web applications
>>>>> to use web-based fonts as the primary set of font choices, but allow users
>>>>> to opt-in to take advantage of their local fonts for specific design 
>>>>> needs.
>>>>>
>>>>> If this feature were removed from the platform, web applications would
>>>>> lose the ability to enumerate local fonts and retrieve font data but
>>>>> otherwise are expected to continue to function.
>>>>>
>>>>> Gecko: https://github.com/mozilla/standards-positions/issues/401
>>>>>
>>>>
>>>> https://github.com/WICG/local-font-access/issues/20 and
>>>> https://github.com/WICG/local-font-access/issues/19 are still open and
>>>> seem to be increasing the interop risk here. Can you expand on plans to
>>>> resolve them?
>>>>
>>>
>> https://github.com/WICG/local-font-access/issues/81 is also related and
>> comes down to: how much do we shield the web app from the contents of font
>> files? At one extreme, the data is normalized into some strict subset,
>> stripping features. At the other, they are treated like files. When we
>> started exploring the API we started in the middle exposing the font data
>> in a more structured way (e.g. tables), but this (1) would lock the API
>> into current font formats/concepts and (2) all sites planning to use the
>> API are using common libraries that consume entire files, which already
>> have robust parsing. So we lean heavily into the "treat them like files" -
>> provide the data and get out of the way of the sites/libraries to use the
>> rich data, similar to uploading images.
>>
>
> So, no normalization happens on the font files? Is that reflected in the
> spec? Did you get any

[blink-dev] Re: Intent to Ship: Local Fonts Access API

['Joshua Bell' via blink-dev]

One thing to call out on the thread since it may not be obvious - per the
chromestatus entry (
https://chromestatus.com/feature/6234451761692672#details) the API will not
ship on Android or WebView at the same time as desktop (W/M/L/CrOs). On
those platforms, the API will not appear, so normal feature detection can
be done.

We'd considered having the API present, but return an empty list, but
thought that could train developers to expect that behavior on mobile
platforms, whereas we do plan to support the API there in the future.


On Wed, Apr 13, 2022 at 9:46 AM Joshua Bell  wrote:

> On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss  wrote:
>
>> Also, any learnings/feedback from the Origin Trial?
>>
>>
> Not distinct from the dev trial (i.e. developers trying the API behind a
> flag). There was a feature request for additional metadata which was
> implemented, then the request was withdrawn so that code was backed out.
> Other requests are marked as "enhancements" in the issue tracker, e.g. font
> modification timestamps.
>
>
>> On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote:
>>
>>> On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote:
>>>
>>>> Contact emails
>>>>
>>>> ds...@chromium.org, jsb...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>> https://github.com/WICG/local-font-access
>>>>
>>>> Specification
>>>>
>>>> https://wicg.github.io/local-font-access/
>>>>
>>>> Design docsDesign Doc: https://bit.ly/2HWBOLi
>>>> <https://chromestatus.com/admin/features/launch/6234451761692672/Design%20Doc:%20https://bit.ly/2HWBOLi>
>>>>
>>>> Blog: https://web.dev/local-fonts/
>>>>
>>>>
>>>> Summary
>>>>
>>>> Gives web applications the ability to enumerate local fonts and some
>>>> metadata about each. Today, no API exists to provide a list of local fonts
>>>> to web applications.
>>>>
>>>> Also gives web applications access to the font data as a binary blob,
>>>> allowing those fonts to be rendered within their applications using custom
>>>> text stacks.
>>>>
>>>> Blink component
>>>>
>>>> Blink>Fonts
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts>
>>>>
>>>> TAG review
>>>>
>>>> https://github.com/w3ctag/design-reviews/issues/400
>>>>
>>>> TAG review status
>>>>
>>>> Pending
>>>>
>>>> RisksInteroperability and Compatibility
>>>>
>>>> This API has been designed to support feature detection to allow
>>>> applications to gracefully degrade based on the capabilities different user
>>>> agents offer.
>>>>
>>>> We expect developers using this API to design their web applications to
>>>> use web-based fonts as the primary set of font choices, but allow users to
>>>> opt-in to take advantage of their local fonts for specific design needs.
>>>>
>>>> If this feature were removed from the platform, web applications would
>>>> lose the ability to enumerate local fonts and retrieve font data but
>>>> otherwise are expected to continue to function.
>>>>
>>>> Gecko: https://github.com/mozilla/standards-positions/issues/401
>>>>
>>>
>>> https://github.com/WICG/local-font-access/issues/20 and
>>> https://github.com/WICG/local-font-access/issues/19 are still open and
>>> seem to be increasing the interop risk here. Can you expand on plans to
>>> resolve them?
>>>
>>
> https://github.com/WICG/local-font-access/issues/81 is also related and
> comes down to: how much do we shield the web app from the contents of font
> files? At one extreme, the data is normalized into some strict subset,
> stripping features. At the other, they are treated like files. When we
> started exploring the API we started in the middle exposing the font data
> in a more structured way (e.g. tables), but this (1) would lock the API
> into current font formats/concepts and (2) all sites planning to use the
> API are using common libraries that consume entire files, which already
> have robust parsing. So we lean heavily into the "treat them like files" -
> provide the data and get out of the way of the sites/libraries to use the
> rich data, similar to uploading images.
>
> The API shape takes an options object, which would

[blink-dev] Re: Intent to Ship: Local Fonts Access API

['Joshua Bell' via blink-dev]

On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss  wrote:

> Also, any learnings/feedback from the Origin Trial?
>
>
Not distinct from the dev trial (i.e. developers trying the API behind a
flag). There was a feature request for additional metadata which was
implemented, then the request was withdrawn so that code was backed out.
Other requests are marked as "enhancements" in the issue tracker, e.g. font
modification timestamps.


> On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote:
>
>> On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote:
>>
>>> Contact emails
>>>
>>> ds...@chromium.org, jsb...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/local-font-access
>>>
>>> Specification
>>>
>>> https://wicg.github.io/local-font-access/
>>>
>>> Design docsDesign Doc: https://bit.ly/2HWBOLi
>>> 
>>>
>>> Blog: https://web.dev/local-fonts/
>>>
>>>
>>> Summary
>>>
>>> Gives web applications the ability to enumerate local fonts and some
>>> metadata about each. Today, no API exists to provide a list of local fonts
>>> to web applications.
>>>
>>> Also gives web applications access to the font data as a binary blob,
>>> allowing those fonts to be rendered within their applications using custom
>>> text stacks.
>>>
>>> Blink component
>>>
>>> Blink>Fonts
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/400
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> RisksInteroperability and Compatibility
>>>
>>> This API has been designed to support feature detection to allow
>>> applications to gracefully degrade based on the capabilities different user
>>> agents offer.
>>>
>>> We expect developers using this API to design their web applications to
>>> use web-based fonts as the primary set of font choices, but allow users to
>>> opt-in to take advantage of their local fonts for specific design needs.
>>>
>>> If this feature were removed from the platform, web applications would
>>> lose the ability to enumerate local fonts and retrieve font data but
>>> otherwise are expected to continue to function.
>>>
>>> Gecko: https://github.com/mozilla/standards-positions/issues/401
>>>
>>
>> https://github.com/WICG/local-font-access/issues/20 and
>> https://github.com/WICG/local-font-access/issues/19 are still open and
>> seem to be increasing the interop risk here. Can you expand on plans to
>> resolve them?
>>
>
https://github.com/WICG/local-font-access/issues/81 is also related and
comes down to: how much do we shield the web app from the contents of font
files? At one extreme, the data is normalized into some strict subset,
stripping features. At the other, they are treated like files. When we
started exploring the API we started in the middle exposing the font data
in a more structured way (e.g. tables), but this (1) would lock the API
into current font formats/concepts and (2) all sites planning to use the
API are using common libraries that consume entire files, which already
have robust parsing. So we lean heavily into the "treat them like files" -
provide the data and get out of the way of the sites/libraries to use the
rich data, similar to uploading images.

The API shape takes an options object, which would allow adding a filter
for font file formats in the future, e.g. {accept: ["font/ttf", "font/off",
"font/woff", "font/woff2"]}, so that sites could limit what types are
provided. I could imagine us adding that and providing a default like the
above if new formats become supported by the web but that might "surprise"
sites.


>
>>
>>> WebKit:
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-April/032176.html
>>>
>>> Web developers: Strongly positive (https://crbug.com/535764#c2) Very
>>> positive support from web applications that interact with local fonts, such
>>> as Figma.
>>>
>>> Adopted by: Boxy SVG 
>>>
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> The feature builds both enumeration and data access into the same new
>>> API. Separation was considered but rejected. (See the Explainer for more
>>> details.) That may limit use.
>>>
>>> Activation
>>>
>>> Developers will be able to take advantage of this feature immediately
>>> since it uses the same available local fonts that other native applications
>>> have access to.  The API makes it possible for web developers to implement
>>> a font picker (either UI-driven or algorithmic) and API usage will see more
>>> traction once popular UI libraries build font pickers on top of it.
>>>
>>> Content for this API is available immediately since the API uses
>>> locally-installed fonts that are already present on the user's system.
>>> Usage of this API by an average web developer will require additional text
>>> shaping software that would render fonts based on data returned by this
>>> API.  (eg.

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item

[Joshua Bell]

Drive-by comment on the thread:

There was a question up-thread about whether the 1s user activation was
sufficient time for real-world use cases. Unfortunately it is not - some
apps that do data transcoding - e.g. image editors that need to composite
multiple layers then do an image format encoding pass - can take longer
than 1s, especially on lower end hardware.

(I've seen this sort of delay in native apps too, with sufficiently large
datasets being copied.)

On Mon, Nov 1, 2021 at 10:01 AM 'Anupam Snigdha' via blink-dev <
blink-dev@chromium.org> wrote:

> Sorry for the late response (I was out on vacation).
>
> *Writing to the clipboard is quite distinct from reading from the
> clipboard, isn't it? https://gifted-stingy-ketchup.glitch.me/
>  actually surfaces a permission
> prompt when executing `navigator.clipboard.read()`, which is more in line
> with my expectations.*
>
>
>
> Yes, it is, but this feature really affects writing to the clipboard as
> the promises to the Blobs are provided by the web authors. Thus, browser is
> not (at least for now) in control of the timing of when the promises are
> resolved. For reading, we are in complete control of the promises. In
> Chromium we read all the supported clipboard formats during the read() call
> and after user grants permission to access the clipboard, and resolve the
> promises with the Blob data. UAs could choose to not do this and may read
> the payload and resolve the Blob data when it’s actually queried via
> getType 
> method.
>
>
>
> *The question in my mind relates to the content of that promise's
> resolution. Is the resulting blob created at the point at which the
> `read()` method is called (as a "copy of the system clipboard data")? Or is
> the resolution "active" in some sense, returning a blob representing
> whatever happens to be in the clipboard at the time the promise is
> resolved?*
>
> At least in chromium, we read the payload from the clipboard corresponding
> to the formats during the read() method call (asynchronously so we don’t
> block the UI thread):
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/clipboard/clipboard_promise.cc;drc=8cc4402c875055fe7989c15f7dfdd04a46c753fc;l=256
>
>
>
> But like I said, write() affects how web authors process the ClipboardItem
> object which in turn affects when the content is written to the clipboard.
> I don’t think there is any issue with the read() API, and this proposal
> doesn’t affect how Chromium reads formats from the clipboard and when the
> promises to the Blobs are resolved.
>
>
>
> *does a click give you access to the clipboard _now_, or at some arbitrary
> point in the future?*
>
> Yes, click gives you access to the clipboard, but promises to the blobs
> don’t have to be resolved within the event handler.
>
> e.g.
>
> Here instead of resolving the promises, you could resolve it later, but
> the call to the write() method needs to happen inside the click event
> handler.
>
> Copy text and markup
>
> Then paste in the box below:
>
> 
>
> 
>
> document.getElementById("copy-html").addEventListener("click", event => {
>
> navigator.clipboard.write([
>
> new ClipboardItem({
>
> "text/plain": Promise.resolve("This text was copied using
> `Clipboard.prototype.write`."),
>
> "text/html": Promise.resolve("
This text was copied using
> Clipboard.prototype.write.
"),
>
> }),
>
> ]);
>
> });
>
> 
>
>
>
>
>
> *From:* Mike West 
> *Sent:* Thursday, October 28, 2021 11:42 PM
> *To:* Anupam Snigdha 
> *Cc:* bratel...@gmail.com; dome...@chromium.org; yoavwe...@chromium.org;
> blink-dev@chromium.org; ann...@annevk.nl; m...@chromium.org; Bo Cupp <
> pc...@microsoft.com>
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship:
> Add support for Promise to Blobs in clipboard item
>
>
>
> On Fri, Oct 29, 2021 at 3:56 AM Anupam Snigdha 
> wrote:
>
> Let me try to clarify few things. Currently there is *no *user activation
> requirements in async clipboard read/write in Chromium browsers. e.g.
> https://clumsy-garnet-meeting.glitch.me/
> .
> Just load this page and refresh it without clicking anywhere on the page,
> you will see the content will get written to the clipboard without any
> gesture.
>
>
>
> Writing to the clipboard is quite distinct from reading from the
> clipboard, isn't it? https://gifted-stingy-ketchup.glitch.m

Re: [blink-dev] Intent to Prototype: Standardize existing client hint naming

[Joshua Bell]

I2Ps don't need any LGTMs. Was there specific feedback you were looking for?

On Wed, Aug 18, 2021 at 10:10 AM Mike Taylor  wrote:

> This I2P seems to have fallen through the cracks (understandably lots of
> vacation happening this month).
> Any thoughts from API owners?
>
> On 8/9/21 2:20 PM, Ari Chivukula wrote:
>
>
>
>
>
>
>
>
> * Contact emails aric...@chromium.org ,
> jadekess...@chromium.org , miketa...@chromium.org
>  Design Doc
> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
> 
> Specification https://wicg.github.io/client-hints-infrastructure/
> 
> https://wicg.github.io/responsive-image-client-hints/
> 
> https://wicg.github.io/savedata/#save-data-request-header-field
> 
> https://wicg.github.io/netinfo/#networkinformation-interface
>  Summary This
> proposal seeks to align our implementation with the Client Hint proposal
>  by adding the
> `sec-ch-` prefix where it’s missing. Blink component Privacy>Fingerprinting
> 
> Motivation Client Hints
> , a method to
> request information about the user's device or conditions, have been
> implemented in Chrome, but since the initial implementation the naming
> scheme has changed. If implemented, this proposal would add new client
> hints with a `sec-ch-` prefix to re-implement the following: `dpr`,
> `width`, `viewport-width`, `device-memory`, `rtt`, `downlink`, and `ect`.
> TAG review Not needed * Risks
>
> * Only Blink implements client hints and we are not (yet) removing any
> current ones, just re-implementing existing ones under the correct name. If
> usage permits, we will remove the legacy names in the future.   * 
> Interoperability
> and Compatibility
>
> Gecko: Client hints not implemented
>
> WebKit: Client hints not implemented
>
> Web developers: Positive interest from Cloudinary
> 
>
> Is this feature fully tested by web-platform-tests?
>
> Yes
> 
>
> Tracking bug
>
> https://crbug.com/1227043
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/6658223894429696
>
>
> --
> 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/7162dcb1-279f-b0f6-4502-6ceb1013980d%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/CAD649j7BodGF%3Dy1Eye-op7wVV-sjhhgKCmVoTKN3MHVAiNBW6w%40mail.gmail.com.