Re: [blink-dev] Intent to Ship: Sync methods for FileSystemSyncAccessHandle in File System Access API

[Yoav Weiss]

LGTM1
Seems good to make this change now, as usage is low, but rising.

Please make sure you reach out to affected partners.

On Fri, Sep 23, 2022 at 7:21 PM Daseul Lee  wrote:

>
>
> On Fri, Sep 23, 2022 at 12:50 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Thu, Sep 22, 2022 at 8:06 PM 'Daseul Lee' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> ds...@google.com
>>>
>>> Specification
>>>
>>>
>>> https://github.com/whatwg/fs/pull/53/commits/618b663ebdc0f9842d7db3091baed5f75aa87534
>>>
>>> Summary
>>>
>>> Updates the asynchronous methods (`flush()`, `getSize()`, `truncate()`)
>>> in `FileSystemSyncAccessHandle` in the File System Access API to
>>> synchronous methods. `FileSystemSyncAccessHandle` currently has a mix of
>>> sync and async methods, hindering the performance and the usability,
>>> especially for applications porting C/C++ to Wasm. This update will bring
>>> consistency in the API usage and improve the performance for Wasm-based
>>> libraries.
>>>
>>>
>>> Blink component
>>>
>>> Blink>Storage>FileSystem
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/772
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Compatibility:
>>>
>>> Changing a return type from Promise to value can break, only if Promise
>>> methods are directly used rather than `await`. However, we expect minimal
>>> breakage due to very low usage (~0.2% page loads; zero usage queried
>>> via HttpArchive).
>>>
>>
>> Do I understand correctly that this usage is a loose upper bound of users
>> of the API, and not necessarily sites that are not using `await`?
>>
> Yes, that's correct. It includes any usage, whether it is `await` or
> `Promise.then()`
>
>
>> Does it include all the APIs that are planned to stop returning Promises?
>> Also, can you link the use counter?
>>
> For truncate() method as an example, here is the link for use counter:
> https://uma.googleplex.com/p/chrome/timeline_v2/?sid=33c4e21724eb85df0bdc19ff775d0018
> Unfortunately, it times out for (unique) count clients, so the above link
> is filtered on Mac OX only. It is still very slow, though.
>

Thanks!
Here are the public link for the same counters:
Truncate - https://chromestatus.com/metrics/feature/timeline/popularity/4019
Flush - https://chromestatus.com/metrics/feature/timeline/popularity/4017
GetSize - https://chromestatus.com/metrics/feature/timeline/popularity/4018


>
> Some other links:
> Page load %:
> https://chromestatus.com/metrics/feature/timeline/popularity/4019
> Additionally, we tried querying HttpArchive directly, and 0 usage has
> returned.
>
> As a side note, we have an enterprise policy set up to guard this change
> to prevent breakage.
>
>>
>>
>>> The original API was shipped in M102 and targeted for partner usage, to
>>> which the changes may be communicated. In addition, all code snippets and
>>> examples in public documents use `await`, which does not cause any breakage.
>>>
>>> Interoperability:
>>>
>>> There are no interoperability risks expected. The design change was
>>> initially proposed and assessed from vendor feedback.
>>> https://github.com/whatwg/fs/issues/7
>>>
>>>
>>> Gecko: Positive (
>>> https://github.com/whatwg/fs/issues/7#issuecomment-1226562961)
>>>
>>> WebKit: No signal
>>>
>>> Web developers: Strongly positive (https://github.com/whatwg/fs/issues/7
>>> )
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> Low ergonomics risks are expected. In fact, the goal of this change is
>>> to improve the ergonomics of the API by making all methods to return
>>> synchronously and make it easier to use on Wasm-ported applications.
>>>
>>>
>>> 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
>>>
>>> Basic tooling: Autocomplete works as described in "New WebIDL/DOM
>>> interfaces and attributes".
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> No
>>>
>>> Desktop only now. Origin Private File System (including
>>> `FileSystemSyncAccessHandle`) is planned to be shipped on Android in the
>>> near future.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> Flag name
>>>
>>> sync-access-handle-all-sync-surface
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1338340
>>>
>>> Estimated milestones
>>>
>>> DevTrial on desktop
>>>
>>> 106
>>>
>>>
>>> Anticipated spec changes
>>>
>>>
>>> https://github.com/whatwg/fs/pull/53/commits/618b663ebdc0f9842d7db3091baed5f75aa87534
>>>
>>> 

[blink-dev] In-person registration is now closed

[BlinkOn Planning Committee]

bcc: blink-dev


Hi everyone,

In-person registration is now closed. We will be reaching out to
individuals who get randomly chosen to attend in-person this upcoming week
where we’ll share travel tips for the area.

Virtual registration will remain open until the start of the event. If you
plan to attend virtually, we strongly encourage you to register ASAP

so that you can stay up to date with all the latest information.

If you have any questions or concerns, don't hesitate to email us at
blin...@chromium.org.

Thanks,

BlinkOn Planning Committee

-- 
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/CABjKNU5DCkU9ZjGNNzSX_8bPzYrA9RwWZ4RSUCeH_nf%2Bwg-Fhw%40mail.gmail.com.

[blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[David Bokan]

Contact emails

bo...@chromium.org

Explainer
https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md

Specification
The resize behavior of the virtual keyboard is not specified.
The viewport meta tag is not yet fully specified 
.
See also https://github.com/w3c/csswg-drafts/issues/7767.

Summary
This intent:

   - Changes the Android virtual keyboard such that it resizes the visual 
   viewport only, rather than the current behavior of resizing the initial 
   containing block (ICB) and layout viewport (LVP).
   - Ships support for a new meta-viewport key interactive-widgets which 
   can be used to opt-out of the above change, and instead retain the old 
   behavior.
   
   Example: 


*Motivation*Browsers do not currently agree on how the virtual keyboard 
should interact with the viewport:

   - 
   
   Chrome for Android and Firefox for Android both resize the initial 
   containing block and  layout viewport.
   - 
   
   Chrome for ChromeOS and Windows; and Safari/iOS both resize the visual 
   viewport only.
   
This discrepancy is a source of frustration for authors [1] 

 
[2] 

 
[3] 

 
[4] . While 
both approaches have valid use-cases, we believe that resizing the visual 
viewport is the best default, as it avoids any layout-jank from opening the 
keyboard, and in general interferes with the page as little as possible.

Other vendors also have long-standing issues in this area: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1007286

This intent improves interop for mobile viewports, a priority investigation 
area for Interop 2022 . Mobile viewports 
(especially the meta tag) are unfortunately not well specified, and we plan 
to work on resolving CSSWG issue 7767 
 in parallel with this 
intent. In the meantime we plan to add this feature to the Compat spec 
.

Blink component
Blink>Scroll 


TAG review
N/A

TAG review status
Not applicable

Risks

Interoperability and Compatibility

The main risk with this change is web apps which critically depend on the 
current LVP-resize behavior, e.g. a chat app with a message box fixed above 
the keyboard.

Those use-cases would no longer be possible with the default behavior, and 
it was exactly this concern that stopped the previous attempt to ship this 
behavior 

 
at LGTM2.

What makes this intent different:

   - 
   
   The VirtualKeyboard API 
    now 
   exists, which exposes the geometry of the keyboard as CSS-reachable 
   environment variables allowing app full control over keyboard behavior.
   - 
   
   For an easier fix, a new  opt-out has been added which can be used 
   to maintain the current LVP-resize behavior. This is a trivial fix for any 
   affected web app.
   
As there is no good way to detect the problematic cases with a use-counter 
/ HTTP Archive query, we must instead rely on developer outreach to inform 
this change. That outreach will reference this intent, and therefore the 
results of that will be provided in a follow-up e-mail.

We expect this change to be a significant win for interop.

*Signals:*

Gecko: No response yet[standards position 
] (Some 
non-official positive signals from Mozilla engineers from discussions at 
TPAC and in 7767 
 
that Firefox could make this change)

WebKit: No response yet [standards position 
]. The change to 
Chromium’s default behavior would now align with WebKit behavior..

Web developers: See “author frustration” links earlier in this e-mail.

Other signals: N/A
WebView application risks

There is no intended behavior change for Android WebView. The Android app 
is responsible for sizing the WebView and can implement either mode via 
windowSoftInputMode 

.
Debuggability

N/A - There's no DevTools functionality directly related to the virtual 
keyboard.
Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?

This change 

Re: [blink-dev] no scrollbar for CSS overflow-y:auto and overflow-y:scroll on Android

[Yi Liu]

Hi, I am searching similar issues and found this thread. Not sure if this 
thread is still active for comments. 

When I use overflow-y: auto on a div element, on android chrome, there will 
be a default scrollbar and will fade out if I am not scrolling; 

But on android webview, the default scrollbar does not show. 

Any idea about the different behaviors between android webview vs android 
chrome?  My device is Galaxy Tab A8, android 11.

Thank you! 
On Monday, August 17, 2015 at 7:04:44 a.m. UTC-7 rby...@chromium.org wrote:

> On Mon, Aug 17, 2015 at 2:45 AM, Elliott Sprehn  
> wrote:
>
>> +rbyers
>>
>> On Sun, Aug 16, 2015 at 11:09 PM, Xing  wrote:
>>
>>> Thanks PhistucK. Is it possible to  enable overlay scrollbar on Android?
>>>
>>>
>> The scroll bar appears when you scroll. There does seem to be a bug in 
>> Chrome that when you switch away from Chrome and then back scrollbars don't 
>> appear and then fade out. They do for native apps which is nice because it 
>> shows you what's scrollable. In fact all new scrollbars on screen appear 
>> and then fade away (ex. when transitioning to a new view), we should do the 
>> same in Chrome.
>>
>
> I filed http://crbug.com/521589 to further discuss the specific issue 
> when switching back to chrome.  Thanks Elliott!
>
>
>
>> - E
>>
>
>

-- 
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/b1317e55-2083-48cc-b143-3dce28893676n%40chromium.org.

Re: [blink-dev] Intent to Ship: Sync methods for FileSystemSyncAccessHandle in File System Access API

['Daseul Lee' via blink-dev]

On Fri, Sep 23, 2022 at 12:50 AM Yoav Weiss  wrote:

>
>
> On Thu, Sep 22, 2022 at 8:06 PM 'Daseul Lee' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> ds...@google.com
>>
>> Specification
>>
>>
>> https://github.com/whatwg/fs/pull/53/commits/618b663ebdc0f9842d7db3091baed5f75aa87534
>>
>> Summary
>>
>> Updates the asynchronous methods (`flush()`, `getSize()`, `truncate()`)
>> in `FileSystemSyncAccessHandle` in the File System Access API to
>> synchronous methods. `FileSystemSyncAccessHandle` currently has a mix of
>> sync and async methods, hindering the performance and the usability,
>> especially for applications porting C/C++ to Wasm. This update will bring
>> consistency in the API usage and improve the performance for Wasm-based
>> libraries.
>>
>>
>> Blink component
>>
>> Blink>Storage>FileSystem
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/772
>>
>> TAG review status
>>
>> Pending
>>
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Compatibility:
>>
>> Changing a return type from Promise to value can break, only if Promise
>> methods are directly used rather than `await`. However, we expect minimal
>> breakage due to very low usage (~0.2% page loads; zero usage queried
>> via HttpArchive).
>>
>
> Do I understand correctly that this usage is a loose upper bound of users
> of the API, and not necessarily sites that are not using `await`?
>
Yes, that's correct. It includes any usage, whether it is `await` or
`Promise.then()`


> Does it include all the APIs that are planned to stop returning Promises?
> Also, can you link the use counter?
>
For truncate() method as an example, here is the link for use counter:
https://uma.googleplex.com/p/chrome/timeline_v2/?sid=33c4e21724eb85df0bdc19ff775d0018
Unfortunately, it times out for (unique) count clients, so the above link
is filtered on Mac OX only. It is still very slow, though.

Some other links:
Page load %:
https://chromestatus.com/metrics/feature/timeline/popularity/4019
Additionally, we tried querying HttpArchive directly, and 0 usage has
returned.

As a side note, we have an enterprise policy set up to guard this change to
prevent breakage.

>
>
>> The original API was shipped in M102 and targeted for partner usage, to
>> which the changes may be communicated. In addition, all code snippets and
>> examples in public documents use `await`, which does not cause any breakage.
>>
>> Interoperability:
>>
>> There are no interoperability risks expected. The design change was
>> initially proposed and assessed from vendor feedback.
>> https://github.com/whatwg/fs/issues/7
>>
>>
>> Gecko: Positive (
>> https://github.com/whatwg/fs/issues/7#issuecomment-1226562961)
>>
>> WebKit: No signal
>>
>> Web developers: Strongly positive (https://github.com/whatwg/fs/issues/7)
>>
>> Other signals:
>>
>> Ergonomics
>>
>> Low ergonomics risks are expected. In fact, the goal of this change is to
>> improve the ergonomics of the API by making all methods to return
>> synchronously and make it easier to use on Wasm-ported applications.
>>
>>
>> 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
>>
>> Basic tooling: Autocomplete works as described in "New WebIDL/DOM
>> interfaces and attributes".
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No
>>
>> Desktop only now. Origin Private File System (including
>> `FileSystemSyncAccessHandle`) is planned to be shipped on Android in the
>> near future.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> Flag name
>>
>> sync-access-handle-all-sync-surface
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1338340
>>
>> Estimated milestones
>>
>> DevTrial on desktop
>>
>> 106
>>
>>
>> Anticipated spec changes
>>
>>
>> https://github.com/whatwg/fs/pull/53/commits/618b663ebdc0f9842d7db3091baed5f75aa87534
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5149644305203200
>>
>> 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/CAPscNz4GPefX650W7y-z2-kDVpwChCWur1UJb2490ySm03jy2A%40mail.gmail.com
>> 

Re: [blink-dev] Intent to Ship: Origin Private File System (OPFS) on Android

['Daseul Lee' via blink-dev]

Thanks for the review!

WPT is no longer available

to run on Android.

It looks like there is some coverage

for Drag-and-Drop, but as Marijn mentioned, it doesn't have full/good
coverage, especially if your original question was with respect to
file-system.


On Thu, Sep 22, 2022 at 2:00 PM Marijn Kruisselbrink 
wrote:

>
>
> On Thu, Sep 22, 2022 at 5:34 AM Mike Taylor 
> wrote:
>
>> LGTM2
>>
>> On 9/22/22 12:04 AM, Yoav Weiss wrote:
>>
>> LGTM1
>>
>> On Wed, Sep 21, 2022 at 9:10 PM 'Daseul Lee' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> No
>>>
>>> Web Platform Tests are not available on Android.
>>>
>>> (The answer should probably be yes here, I think.)
>>
>> Out of curiosity, do we have (manual?) tests that cover the DnD
>> functionality that this intent does not support, for Desktop? I see there
>> are some showPicker tests.
>>
> There are browser tests for the DnD functionality. Chrome's web platform
> test infrastructure bypasses so much of chrome's drag implementation
> that even if we would/could write a WPT that would try to exercise the DnD
> code (there are some for other file DnD features) we're not really testing
> the real implementation anymore.
>
>>
>> https://wpt.fyi/results/file-system-access?label=master=experimental=subtest
>>
>> thanks,
>> Mike
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8ee76bfb-45b8-f0bf-a3bf-82d9ea0d78c5%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/CAPscNz4ePE1kkTJLaZz9W-CdNLPgu%3D1Bmd-0zkso2-qMZc4Ajw%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Web Smart Card API

[Tom Jones]

It is not possible to get onto DOD sites today without loading certs, so
there are lots of hills to climb.
I would like to start testing this asap - what do I need to do?
..tom


On Fri, Sep 23, 2022 at 9:09 AM Christian Biesinger 
wrote:

> While I don't know if this specific proposal would support it, things like
> the various EU countries' citizen cards (using their national IDs for
> authenticating to government services) do not use TLS client certs, instead
> relying on other software that needs to be installed.
>
> Christian
>
> On Wed, Sep 21, 2022 at 5:13 PM agowa338  wrote:
>
>> What's the difference between this proposal to just using HTTPS client
>> auth with a certificate on a smartcard? That's basically what we've been
>> using for decades now...
>>
>> rei...@chromium.org schrieb am Mittwoch, 21. September 2022 um 20:41:56
>> UTC+2:
>>
>>> Not mentioned above but included in the explainer: To mitigate some of
>>> the obvious security concerns this API will only be available to Isolated
>>> Web Apps .
>>> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome
>>> 
>>>
>>>
>>> On Wed, Sep 21, 2022 at 8:00 AM 'Daniel d'Andrada' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emailsdand...@google.com

 Explainer
 https://github.com/dandrader/web-smart-card/blob/main/README.md

 Summary

 Enables smart card (PC/SC) applications to move to the Web platform. It
 gives them access to the PC/SC implementation (and card reader drivers)
 available in the host OS.


 Blink componentBlink
 

 Motivation

 While there are other APIs that provide the right level of abstraction
 and security properties for identity on the Web, such as WebAuthn, there
 are domain-specific functions which can't be captured by such higher-level
 APIs. A remote access (aka "remote desktop") web app letting the remote
 machine access the host's card reader as if it were directly connected to
 it. Enabling PC/SC applications on that remote machine to work without
 modification, unaware that the card reader is not local. A web-based kiosk
 could read even simple RFID badges via PC/SC and then display relevant
 information on a screen. It's also not uncommon for such readers to need
 control commands to put them into the proper state for reading the
 particular type of card the application supports.


 Initial public proposalhttps://github.com/WICG/proposals/issues/64

 TAG review statusPending

 Risks


 Interoperability and Compatibility



 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*: PC/SC developers. Generally positive. (see e-mail
 thread
 
 )

 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



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

 Flag nameSmartCard

 Requires code in //chrome?Yes. Similarly to other device APIs like
 WebHID and WebUSB.

 Estimated milestones

 No milestones specified


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

 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+...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BenBd9j9Ucy-BKqfQSk9hZxVG6-qm4H6X3%3DxT9U86KpiOpKeA%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/2539271a-7eee-468b-8e28-17f19ad4ed02n%40chromium.org
>> 

Re: [blink-dev] Intent to Prototype: Web Smart Card API

[Christian Biesinger]

While I don't know if this specific proposal would support it, things like
the various EU countries' citizen cards (using their national IDs for
authenticating to government services) do not use TLS client certs, instead
relying on other software that needs to be installed.

Christian

On Wed, Sep 21, 2022 at 5:13 PM agowa338  wrote:

> What's the difference between this proposal to just using HTTPS client
> auth with a certificate on a smartcard? That's basically what we've been
> using for decades now...
>
> rei...@chromium.org schrieb am Mittwoch, 21. September 2022 um 20:41:56
> UTC+2:
>
>> Not mentioned above but included in the explainer: To mitigate some of
>> the obvious security concerns this API will only be available to Isolated
>> Web Apps .
>> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome
>> 
>>
>>
>> On Wed, Sep 21, 2022 at 8:00 AM 'Daniel d'Andrada' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emailsdand...@google.com
>>>
>>> Explainerhttps://github.com/dandrader/web-smart-card/blob/main/README.md
>>>
>>> Summary
>>>
>>> Enables smart card (PC/SC) applications to move to the Web platform. It
>>> gives them access to the PC/SC implementation (and card reader drivers)
>>> available in the host OS.
>>>
>>>
>>> Blink componentBlink
>>> 
>>>
>>> Motivation
>>>
>>> While there are other APIs that provide the right level of abstraction
>>> and security properties for identity on the Web, such as WebAuthn, there
>>> are domain-specific functions which can't be captured by such higher-level
>>> APIs. A remote access (aka "remote desktop") web app letting the remote
>>> machine access the host's card reader as if it were directly connected to
>>> it. Enabling PC/SC applications on that remote machine to work without
>>> modification, unaware that the card reader is not local. A web-based kiosk
>>> could read even simple RFID badges via PC/SC and then display relevant
>>> information on a screen. It's also not uncommon for such readers to need
>>> control commands to put them into the proper state for reading the
>>> particular type of card the application supports.
>>>
>>>
>>> Initial public proposalhttps://github.com/WICG/proposals/issues/64
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*: PC/SC developers. Generally positive. (see e-mail
>>> thread
>>> 
>>> )
>>>
>>> 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
>>>
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag nameSmartCard
>>>
>>> Requires code in //chrome?Yes. Similarly to other device APIs like
>>> WebHID and WebUSB.
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6411735804674048
>>>
>>> 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+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BenBd9j9Ucy-BKqfQSk9hZxVG6-qm4H6X3%3DxT9U86KpiOpKeA%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/2539271a-7eee-468b-8e28-17f19ad4ed02n%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 

Re: [blink-dev] Intent to Deprecate and Remove: navigation to filesystem: URLs in iframes

[Mike Taylor]

Hi Adrian,

Let me follow up off-list to understand your setup in more detail.

Thanks,
Mike

On 9/23/22 11:10 AM, Adrian Holmes wrote:
Is it possible to disable this feature via the registry?  We're a 
digital signage company, and many of our clients use HTML apps which 
are stored in the filesystem and loaded via an iFrame as pointed out 
by Eric.


We are using Chrome Enterprise.

Many thanks



On Thursday, 18 August 2022 at 18:27:09 UTC+1 Eric Melgaard wrote:

This was heavily used in an enterprise product to play HTML
content via iframes in a signage application.

Depreciation or preventing 3rd party access would have been
appreciated since persistent storage owned by the application,
should be accessible to the application.

On Friday, June 3, 2022 at 9:54:16 AM UTC-5 rby...@chromium.org wrote:

I checked the WebView-specific UseCounter too and it's half
that of the Android one. So yeah, it seems extremely unlikely
to me that anyone will notice this - more like a bug-fix than
a deprecation. LGTM3

On Fri, Jun 3, 2022 at 3:23 AM Yoav Weiss
 wrote:

LGTM2

On Thu, Jun 2, 2022 at 8:20 PM Daniel Bratell
 wrote:

Well below our customary threshold level, and unlikely
to be used in our blind spots (WebView, enterprise). I
think it's safe to remove directly.

LGTM1

/Daniel

On 2022-06-02 19:40, Mike Taylor wrote:


**


*Contact emails*

*

mike...@chromium.org, m...@chromium.org


Summary

We propose to remove support for navigating to
filesystem:// URLs in iframes.


Blink component

Blink>Storage>FileSystem




Motivation

Render-initiated navigations to filesystem:// URLs
are blocked in top-level frames, but are currently
allowed in iframes. As part of the storage
partitioning efforts, we propose to remove support
for navigation to filesystem:// URLs in iframes.
Preventing navigation in third-party contexts would
be sufficient for our privacy goals, but as usage is
almost non-existent, we believe removing support for
navigation in iframes altogether is the better approach.


(https://miketaylr.com/misc/filesystem-navigation.html
may
be useful to grok what any of this means.)


TAG review

N/A. This intent refers to a Chromium-only feature
(which we’re trying to remove).


Risks


Interoperability and Compatibility

No other engine supports filesystem:// URLs, so we do
not expect interoperability issues.


As for compatibility, usage is very, very low.
Currently just above 0.008%

.
For this reason we would like to just remove it,
without any deprecation period.


Gecko: N/A (not supported)


WebKit: N/A (not supported)


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?


No.



Debuggability

We currently send an error message to the console if
you try to open a window to a filesystem:// URL - we
will do something similar for iframes.


Is this feature fully tested by
web-platform-tests

?

No


Flag name

FileSystemUrlNavigation


Requires code in //chrome?

False


Estimated milestones

M105



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5816343679991808



This intent message was generated by Chrome Platform
Status 

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Yoav Weiss]

On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:

> Hello Yoav and Mike,
>
> Thanks for the feedback! I replied inline.
> On 9/23/22 22:18, Yoav Weiss wrote:
>
>
>
> On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor 
> wrote:
>
>> Hi Byungwoo,
>>
>> On 9/23/22 4:34 AM, Byungwoo Lee wrote:
>>
>> Contact emails b...@igalia.com
>>
>> Specification
>> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
>>
>> Summary
>>
>> Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) If
>> an argument of the functional selectors is unknown or invalid, the argument
>> is dropped but the selector itself is not invalidated. To provide a way of
>> detecting the unknown or invalid arguments in those functional selectors,
>> this feature applies the CSS Working Group issue resolution: - @supports
>> uses non-forgiving parsing for all selectors (
>> https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)
>>
>> Am I understanding correctly that content that now uses a functional
> selector argument that's invalid may break as a result of this?
> If so, do we have usecounters to that effect?
>
> Yes it can change the previous behavior.
>
> This changes the selector parsing behavior only for the selectors inside
> @supports selector().
>
> So if authors expected true for '@supports
> selector(:is(:some-invalid-selector))', this feature will break it because
> the return value will be changed to false after this feature is enabled.
>
> I'm not sure that we have the usecounters of the case: counting drop of
> invalid selector inside @supports selector.
>
> If it doesn't exists but it is needed, I think we can add it. Will it be
> better to add it to get use counters before ship it?
>

Yeah, knowing the order of magnitude of potential breakage would be good.

>
>>
>> Blink component Blink
>> 
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Can you expand on why you think a TAG review is not needed here?
>>
> I thought that we don't need TAG review and the reason was
>
> - This is already specified in the spec:
> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
> 
>
> - Firefox already landed it:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
>
> Will it be better to change the TAG review status to 'Pending'?
>
>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: Shipped/Shipping
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
>>
>> *WebKit*: Positive
>>
>> *Web developers*: Positive
>>
>> Can you please link to these signals?
>>
>
> WebKit:
>
> - Explained about this in a blog post:
>   https://webkit.org/blog/13096/css-has-pseudo-class/
>
> Web developers:
>
> - Thumbs ups in the CSSWG issue:
>https://github.com/w3c/csswg-drafts/issues/7280
>
> - jQuery applied the spec:
>   https://github.com/jquery/jquery/pull/5107
>
>
> thanks,
>> Mike
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b03b90af-3911-40b4-dd6f-b12764826cf1%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/CAL5BFfXTLU_5ii0mkYJ1wP08tajuB6tYFDjv-OfTKUUHwcnrpQ%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: navigation to filesystem: URLs in iframes

[Adrian Holmes]

Is it possible to disable this feature via the registry?  We're a digital 
signage company, and many of our clients use HTML apps which are stored in 
the filesystem and loaded via an iFrame as pointed out by Eric.

We are using Chrome Enterprise.

Many thanks



On Thursday, 18 August 2022 at 18:27:09 UTC+1 Eric Melgaard wrote:

> This was heavily used in an enterprise product to play HTML content via 
> iframes in a signage application.
>
> Depreciation or preventing 3rd party access would have been appreciated 
> since persistent storage owned by the application, should be accessible to 
> the application. 
>
> On Friday, June 3, 2022 at 9:54:16 AM UTC-5 rby...@chromium.org wrote:
>
>> I checked the WebView-specific UseCounter too and it's half that of the 
>> Android one. So yeah, it seems extremely unlikely to me that anyone will 
>> notice this - more like a bug-fix than a deprecation. LGTM3
>>
>> On Fri, Jun 3, 2022 at 3:23 AM Yoav Weiss  wrote:
>>
>>> LGTM2
>>>
>>> On Thu, Jun 2, 2022 at 8:20 PM Daniel Bratell  wrote:
>>>
 Well below our customary threshold level, and unlikely to be used in 
 our blind spots (WebView, enterprise). I think it's safe to remove 
 directly.

 LGTM1

 /Daniel
 On 2022-06-02 19:40, Mike Taylor wrote:

 *Contact emails* 
























 * mike...@chromium.org, m...@chromium.org Summary We propose to remove 
 support for navigating to filesystem:// URLs in iframes. Blink component 
 Blink>Storage>FileSystem 
 
  
 Motivation Render-initiated navigations to filesystem:// URLs are blocked 
 in top-level frames, but are currently allowed in iframes. As part of the 
 storage partitioning efforts, we propose to remove support for navigation 
 to filesystem:// URLs in iframes. Preventing navigation in third-party 
 contexts would be sufficient for our privacy goals, but as usage is almost 
 non-existent, we believe removing support for navigation in iframes 
 altogether is the better approach. 
 (https://miketaylr.com/misc/filesystem-navigation.html 
  may be useful to 
 grok what any of this means.) TAG review N/A. This intent refers to a 
 Chromium-only feature (which we’re trying to remove). Risks 
 Interoperability and Compatibility No other engine supports filesystem:// 
 URLs, so we do not expect interoperability issues. As for compatibility, 
 usage is very, very low. Currently just above 0.008% 
 . For 
 this reason we would like to just remove it, without any deprecation 
 period. Gecko: N/A (not supported) WebKit: N/A (not supported) 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? No. 
 Debuggability We currently send an error message to the console if you try 
 to open a window to a filesystem:// URL - we will do something similar for 
 iframes. Is this feature fully tested by web-platform-tests 
 ?
  
 No Flag name FileSystemUrlNavigation Requires code in //chrome? False 
 Estimated milestones M105 Link to entry on the Chrome Platform Status 
 https://chromestatus.com/feature/5816343679991808 
  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+...@chromium.org.
 To view this discussion on the web visit 
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/84b7af7f-66fb-4874-0290-f0b22f51cb52%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+...@chromium.org.
 To view this discussion on the web visit 
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b9ca44ab-0655-8e86-a714-aad7ea463b25%40gmail.com
  
 

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

Hello Yoav and Mike,

Thanks for the feedback! I replied inline.

On 9/23/22 22:18, Yoav Weiss wrote:



On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  
wrote:


Hi Byungwoo,

On 9/23/22 4:34 AM, Byungwoo Lee wrote:



Contact emails

b...@igalia.com


Specification

https://drafts.csswg.org/css-conditional-4/#support-definition-ext


Summary

Some functional selectors are parsed forgivingly. (e.g. :is(),
:has()) If an argument of the functional selectors is unknown or
invalid, the argument is dropped but the selector itself is not
invalidated. To provide a way of detecting the unknown or invalid
arguments in those functional selectors, this feature applies the
CSS Working Group issue resolution: - @supports uses
non-forgiving parsing for all selectors
(https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)

Am I understanding correctly that content that now uses a functional 
selector argument that's invalid may break as a result of this?

If so, do we have usecounters to that effect?


Yes it can change the previous behavior.

This changes the selector parsing behavior only for the selectors inside 
@supports selector().


So if authors expected true for '@supports 
selector(:is(:some-invalid-selector))', this feature will break it 
because the return value will be changed to false after this feature is 
enabled.


I'm not sure that we have the usecounters of the case: counting drop of 
invalid selector inside @supports selector.


If it doesn't exists but it is needed, I think we can add it. Will it be 
better to add it to get use counters before ship it?





Blink component

Blink



TAG review



TAG review status

Not applicable


Can you expand on why you think a TAG review is not needed here?


I thought that we don't need TAG review and the reason was

- This is already specified in the spec:
https://drafts.csswg.org/css-conditional-4/#support-definition-ext

- Firefox already landed it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1789248

Will it be better to change the TAG review status to 'Pending'?



Risks



Interoperability and Compatibility



/Gecko/:
Shipped/Shippinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1789248

/WebKit/: Positive

/Web developers/: Positive

Can you please link to these signals?



WebKit:

- Explained about this in a blog post:
https://webkit.org/blog/13096/css-has-pseudo-class/

Web developers:

- Thumbs ups in the CSSWG issue:
https://github.com/w3c/csswg-drafts/issues/7280

- jQuery applied the spec:
https://github.com/jquery/jquery/pull/5107



thanks,
Mike


-- 
You received this message because you are subscribed to the Google

Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b03b90af-3911-40b4-dd6f-b12764826cf1%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/b0b38344-3a85-a30f-1a12-fd897108c340%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Yoav Weiss]

On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  wrote:

> Hi Byungwoo,
>
> On 9/23/22 4:34 AM, Byungwoo Lee wrote:
>
> Contact emails b...@igalia.com
>
> Specification
> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
>
> Summary
>
> Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) If
> an argument of the functional selectors is unknown or invalid, the argument
> is dropped but the selector itself is not invalidated. To provide a way of
> detecting the unknown or invalid arguments in those functional selectors,
> this feature applies the CSS Working Group issue resolution: - @supports
> uses non-forgiving parsing for all selectors (
> https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)
>
> Am I understanding correctly that content that now uses a functional
selector argument that's invalid may break as a result of this?
If so, do we have usecounters to that effect?

>
>
> Blink component Blink
> 
>
> TAG review
>
> TAG review status Not applicable
>
> Can you expand on why you think a TAG review is not needed here?
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> *Gecko*: Shipped/Shipping
> https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
>
> *WebKit*: Positive
>
> *Web developers*: Positive
>
> Can you please link to these signals?
>
> thanks,
> Mike
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b03b90af-3911-40b4-dd6f-b12764826cf1%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/CAL5BFfWUar6mJ%3Dg%3DEycn0oorZVy%3DkHoccffAkUAb7G3u3R0hig%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Mike Taylor]

Hi Byungwoo,

On 9/23/22 4:34 AM, Byungwoo Lee wrote:



Contact emails

b...@igalia.com


Specification

https://drafts.csswg.org/css-conditional-4/#support-definition-ext


Summary

Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) 
If an argument of the functional selectors is unknown or invalid, the 
argument is dropped but the selector itself is not invalidated. To 
provide a way of detecting the unknown or invalid arguments in those 
functional selectors, this feature applies the CSS Working Group issue 
resolution: - @supports uses non-forgiving parsing for all selectors 
(https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)




Blink component

Blink 


TAG review



TAG review status

Not applicable


Can you expand on why you think a TAG review is not needed here?



Risks



Interoperability and Compatibility



/Gecko/: 
Shipped/Shippinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1789248


/WebKit/: Positive

/Web developers/: Positive

Can you please link to these signals?

thanks,
Mike

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

[blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

   Contact emails

b...@igalia.com


   Specification

https://drafts.csswg.org/css-conditional-4/#support-definition-ext


   Summary

Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) 
If an argument of the functional selectors is unknown or invalid, the 
argument is dropped but the selector itself is not invalidated. To 
provide a way of detecting the unknown or invalid arguments in those 
functional selectors, this feature applies the CSS Working Group issue 
resolution: - @supports uses non-forgiving parsing for all selectors 
(https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)




   Blink component

Blink 


   TAG review



   TAG review status

Not applicable


   Risks



   Interoperability and Compatibility



/Gecko/: 
Shipped/Shippinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1789248


/WebKit/: Positive

/Web developers/: Positive

/Other signals/:


   WebView application risks

No



   Debuggability

This can be tested by calling 'CSS.supports()' in the DevTools 
Console window.




   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 byweb-platform-tests
   
?

Yes

 * 
https://wpt.fyi/results/css/css-conditional/at-supports-selector-detecting-invalid-in-forgiving-argument.html
 * 
https://wpt.fyi/results/css/css-conditional/js/CSS-supports-selector-detecting-invalid-in-forgiving-argument.html


   Flag name



   Requires code in //chrome?

False


   Launch bug

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


   Estimated milestones

109



   Anticipated spec changes

The issue is resolved and closed : 
https://github.com/w3c/csswg-drafts/issues/7280




   Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6177049203441664

This intent message was generated byChrome 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/5a9733cb-d530-0e76-45a8-08423dfdbd56%40igalia.com.