[blink-dev] Intent to Ship: removing the five-minute rule for

[Noam Rosenthal]

Contact emails

nrosent...@chromium.org

Explainer

No specific explainer, but all the details are here:
https://chromestatus.com/feature/5087526916718592?context=myfeatures

https://bugs.chromium.org/p/chromium/issues/detail?id=1345207=5%20minute=3


Spec

This feature was never specified!

A new PR to the HTML spec to clarify how prefetch is supposed to work does
not include this removed feature: https://github.com/whatwg/html/pull/8111


Summary

- Currently, when a document includes  and then a
resource tries to consume it, cache-control semantics (max-age, no-cache
etc) are ignored for 5 minutes.

- This was originally introduced when prefetches were meant for
cross-origin navigations (think search engine results), as the prefetching
page had no control over the caching semantics of the prefetched page

- Since introducing partitioned caching,  no longer
works for cross-origin navigation anyway, so that initial use-case is
irrelevant.

- Data from UMA shows

that the vast majority of prefetch reuses don't benefit from this - only
*0.05%*. The rest are either anyway within the cache max-age, outside the 5
minutes, or reused past the first time. This makes this a niche feature
that apart from adding a bit of confusion to the mix does very little.

- Additional supporting data from HTTP archive

shows
that the web dev community is not using prefetch for cross-origin
navigations, but rather mainly for same-origin early fetching of styles and
scripts (only *4%* of pefetches are for cross-origin navigations).

- The data shows that  transitioned from being a feature
for search-type pages into a feature for home/landing pages: e.g. you have
a very fast landing page without scripts and a link to the full web-app
page, and you prefetch the scripts and style of the heavy app to make it
load faster once you click the link

Link to “Intent to Prototype” blink-dev discussion

Link to the blink-dev discussion about implementation. Here’s a link to the
Google Groups page for blink-dev

.

Link to Origin Trial feedback summary

There was no origin trial. Users would barely feel the impact of this.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?

Yes

Demo link

N/A

Debuggability

Web devs can see the impact of this in their network panel.


Measurement

It's a removal, and current use of the feature is marginal at best
(potentially arbitrary and inconsequential).

Risks

Interoperability and Compatibility

This fix is interoperable with firefox, and Safari folks are positive
 about
implementing fetch with the proposed behavior (without the 5-minute rule);

Ergonomics

It's a feature removal that very few rely on. The new speculation-rules
prefetch  should be a
replacement for cross-origin navigational prefetch.

Activation

The very few developers who currently rely on the 5-minute can explicitly
make the same behavior work using Cache-Control headers.

Is this feature fully tested by web-platform-tests
?
Link to test suite results from wpt.fyi.

PR for prefetch behavior pending spec merging:
https://github.com/web-platform-tests/wpt/pull/35707



Entry on the feature dashboard 

https://chromestatus.com/feature/5087526916718592

-- 
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/CAJn%3DMYa7YN%3DdePW5E9LQ2Qpo72r2h3m%3DVKdXfTg910U7AC51_w%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: baseline-source

['Ian Kilpatrick' via blink-dev]

Ah true! I didn't consider the  values here.

To mitigate this forward compat concern we can apply a partial mapping,
e.g. if the current `vertical-align` property is set, it'll set the
`baseline-source` to `auto`.

This should mitigate any forward compat concern here. I'll send a patch to
do this tomorrow. This will allow us to perform the larger (complex, and
risky) vertical-align changes in one shot later.

Ian

On Thu, Jan 12, 2023 at 6:20 PM fantasai 
wrote:

> On 1/12/23 17:21, Ian Kilpatrick wrote:
> > Some additional context for folks:
> >
> >   - Shipping the `baseline-source` property separately (this intent)
> doesn't
> > increase/decrease forwards compat risk in a material way - specifying it
> would
> > "win" over anything specified in `vertical-align` once we support that
> > mapping, and addresses a large web developer concern.
>
> This is incorrect. In an implementation that implements the shorthanding
> relationship vs an implementation that doesn't, the following two
> declarations
> will have different effects:
>
> .x {
>baseline-source: first;
>vertical-align: 10px; /* resets baseline-source to auto, or not */
> }
>
> ~fantasai
>
>

-- 
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/CAJL3UpQ7QpGE2jJp6D26LT7dtt63tz_QU-cWqw7p%3D%2BULqSC-tg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [blink-dev] Intent to Ship: baseline-source

[fantasai]

On 1/12/23 17:21, Ian Kilpatrick wrote:

Some additional context for folks:

  - Shipping the `baseline-source` property separately (this intent) doesn't 
increase/decrease forwards compat risk in a material way - specifying it would 
"win" over anything specified in `vertical-align` once we support that 
mapping, and addresses a large web developer concern.


This is incorrect. In an implementation that implements the shorthanding 
relationship vs an implementation that doesn't, the following two declarations 
will have different effects:


.x {
  baseline-source: first;
  vertical-align: 10px; /* resets baseline-source to auto, or not */
}

~fantasai

--
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/76223aa7-76ba-08b0-e813-a8758862fd73%40inkedblade.net.

Re: [blink-dev] Re: List decorators on Chrome Status

[Joe Pea (Joseph Orbegoso Pea)]

> My best guess would be https://github.com/tc39/proposal-decorators

Yes indeed that's what I was asking about.

> that'd be a V8 question, not a Blink question

That makes sense. The "Discuss" link in the footer of the chromestatus.com 
site links to this group.

On Wednesday, January 11, 2023 at 8:03:28 AM UTC-8 km...@chromium.org wrote:

> My best guess would be https://github.com/tc39/proposal-decorators, but 
> that'd be a V8 question, not a Blink question.
>
> On Wed, Jan 11, 2023 at 7:43 AM 'Jason Robbins' via blink-dev <
> blin...@chromium.org> wrote:
>
>> What do you mean by "decorators"?
>>
>> On Tuesday, January 10, 2023 at 5:54:04 PM UTC-8 tru...@gmail.com wrote:
>>
>>> I don't see "decorators" at https://chromestatus.com/newfeatures. Can 
>>> we add it? - Joe
>>
>> -- 
>> 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/a6c78d37-9b9c-4e01-b4dd-0c5704ce920cn%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/9ae955f6-f7d9-4f10-9e26-0211e5661b42n%40chromium.org.

Re: [blink-dev] Intent to Ship: baseline-source

['Ian Kilpatrick' via blink-dev]

Some additional context for folks:

 - `vertical-align` currently (in all browsers) doesn't map to any other
properties, it supports a bunch of keywords, *or* a  for adjusting
position within a line-box as well as some historical alignment within a
table-cell.

 - The css-inline-3 spec addresses some additional use-cases via. mapping
`vertical-align` onto three properties (`baseline-shift`,
`alignment-baseline`, and `baseline-source`). Specifically this creates
some additional capability being able to specify `vertical-align: text-top
10px` for example which isn't supported at the moment. There is a (very)
small compat risk here.

 - Two of these properties already exist today (and this intent would ship
the third). The first part of the complexity here is that `baseline-shift`,
`alignment-baseline` *only* work on SVG elements today, and
`vertical-align` doesn't. A (very) small compat risk exists that
`vertical-align` would start working for some SVG elements, and the
`baseline-shift`, `alignment-baseline` properties would start working on
other elements as well (2nd part of compat risk here).

 - To support this there is a lot of subtle work involved in supporting
these properties within the inline code, (and arguably table code), it
isn't a "simple" mapping `vertical-align` onto these new properties. Lots
of work needs to be done, lots of tests, etc, we'd like to do this as a
separate phase/project.

 - Shipping the `baseline-source` property separately (this intent) doesn't
increase/decrease forwards compat risk in a material way - specifying it
would "win" over anything specified in `vertical-align` once we support
that mapping, and addresses a large web developer concern.

Ian

On Thu, Jan 12, 2023 at 1:28 PM Ian Kilpatrick 
wrote:

>
>
> On Thu, Jan 12, 2023 at 1:24 PM fantasai 
> wrote:
>
>> On 1/9/23 13:24, Ian Kilpatrick wrote:
>>
>> Contact emails ikilpatr...@chromium.org
>>
>> Explainer None
>>
>> Specification https://drafts.csswg.org/css-inline-3/#baseline-source
>>
>> Summary
>>
>> The "baseline-source" properties allows web developers to specify if an
>> inline-level box should use the "first" or "last" baseline for alignment
>> within an linebox.
>> ...
>>
>>
>> This property is a longhand of `vertical-align`, alongside
>> `baseline-shift` and `alignment-baseline`. Are you planning to ship this
>> set together? (It's probably fine to drop newer values from the other
>> longhands, but their relationships should be implemented correctly, imho.)
>>
>> ~fantasai
>>
>
> No just the baseline-source longhand for the moment - there is additional
> complexity/risks with the vertical-align mapping that we'd like to analyze
> separately.
>
> Ian
>

-- 
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/CAJL3UpQY%2B10SFOdXvwKQNZijBQBn_%3D7ArgmB8P71PULEr58Ogw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [blink-dev] Intent to Ship: baseline-source

['Ian Kilpatrick' via blink-dev]

On Thu, Jan 12, 2023 at 1:24 PM fantasai 
wrote:

> On 1/9/23 13:24, Ian Kilpatrick wrote:
>
> Contact emails ikilpatr...@chromium.org
>
> Explainer None
>
> Specification https://drafts.csswg.org/css-inline-3/#baseline-source
>
> Summary
>
> The "baseline-source" properties allows web developers to specify if an
> inline-level box should use the "first" or "last" baseline for alignment
> within an linebox.
> ...
>
>
> This property is a longhand of `vertical-align`, alongside
> `baseline-shift` and `alignment-baseline`. Are you planning to ship this
> set together? (It's probably fine to drop newer values from the other
> longhands, but their relationships should be implemented correctly, imho.)
>
> ~fantasai
>

No just the baseline-source longhand for the moment - there is additional
complexity/risks with the vertical-align mapping that we'd like to analyze
separately.

Ian

-- 
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/CAJL3UpQKTOC22%2BVevaNuhuKP2qp%2B2Oug-RuBsYyVzbQ%2BiOnq5Q%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [blink-dev] Intent to Ship: baseline-source

[fantasai]

On 1/9/23 13:24, Ian Kilpatrick wrote:



Contact emails

ikilpatr...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-inline-3/#baseline-source


Summary

The "baseline-source" properties allows web developers to specify if an 
inline-level box should use the "first" or "last" baseline for alignment 
within an linebox.


...



This property is a longhand of `vertical-align`, alongside `baseline-shift` 
and `alignment-baseline`. Are you planning to ship this set together? (It's 
probably fine to drop newer values from the other longhands, but their 
relationships should be implemented correctly, imho.)


~fantasai

--
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/47ad5e22-f2b0-0792-9c72-a276f4119585%40inkedblade.net.

Re: [blink-dev] Intent to Ship: Network State Partitioning

['Brianna Goldstein' via blink-dev]

Updating this thread to track that this was ramped up to 10% stable this
week. Estimated milestones remain:

Estimated milestones

Ship at 1% on December 13th - M108

Ship at 10% on January 9th - M109

Ship at 100% on January 23rd - M109





On Mon, Dec 12, 2022 at 2:37 PM Mike West  wrote:

> LGTM3.
>
> Thanks for your close collaboration with the security team here; I think
> the compromise you landed on is both reasonable and good.
>
> -mike
>
>
> On Mon, Dec 12, 2022 at 8:13 PM Chris Harrelson 
> wrote:
>
>> LGTM2
>>
>> On Fri, Dec 2, 2022 at 1:33 AM Yoav Weiss  wrote:
>>
>>> LGTM1
>>>
>>> Thanks for working on this compromise between our security/privacy needs
>>> and our performance goals!!
>>>
>>> On Thu, Dec 1, 2022 at 9:38 PM 'Brianna Goldstein' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 brgoldst...@chromium.org, mme...@chromium.org, a...@google.com,
 miketa...@chromium.org

 Explainer


 https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md

 Specification

 https://fetch.spec.whatwg.org/#connections

 Summary

 Partition network state by the network partition key to protect against
 cross-site tracking through the use of side channels. The network partition
 key consists of the schemeful site of the top level frame and a boolean
 indicating if the request is coming from a cross-site iframe. "Network
 State" here includes connections (H1, H2, H3, websocket), the DNS cache,
 ALPN/H2 support data, TLS/H3 resumption information, Reporting/NEL
 configuration and uploads.

 Unpartitioned network state allows for side-channel timing attacks,
 where one site can figure out if another has been visited recently. For
 example, if the connection is made quickly, it may be assumed that a
 connected socket exists. It also allows for third parties to track users
 across first party contexts they are loaded in using a variety of
 techniques (tracking socket reuse, using per-user alternative service
 advertisements, etc).

 Our initial attempt to partition the network state re-used the triple
 key partition scheme that was shipped for the HTTP cache
 . This included the
 schemeful sites of the top-level frame and the iframe. However, in an
 attempt to land a favorable balance between (1) the performance benefits of
 shared resources, and (2) the privacy promises of ensuring sites are safely
 prevented from gaining information about a user’s browsing habits, this new
 partition key consists of the top level site and a boolean indicating if
 the request is coming from a cross-site iframe.

 Partitioning may reduce Chromium’s ability to reuse network resources.
 We’ve enabled network state partitioning in a 1% experiment on Stable. From
 our experiments, Android navigation times to first contentful paint are
 increased by around 0.35% at the 50th percentile and 0.17% at the 99th
 percentile. Cross-site iframe navigation time to first contentful paints is
 increased by 2.85% at the 50th percentile and 1.35% at the 99th percentile.
 This represents about a 40 ms increase at the 50th percentile. On desktop,
 navigation times to first contentful paint are increased by around 1.00% at
 the 50th percentile (approximately a 10 ms increase) and have no impact on
 the 99th percentile. For cross-site iframes, the navigation times to first
 contentful paint are increased by 1.84% at the 50th percentile and 2.05% at
 the 99th percentile.

>>>
>>> The numbers still don't make me leap of joy, but they are
>>> significantly more reasonable than the previous iteration.
>>> I'm curious about the p75 numbers, but assuming they are somewhere in
>>> between, that probably won't change the outcome.
>>>
>>> I wonder if speculative preconnection using the right key could have
>>> bought back some of this. I similarly wonder if it could've been safe to
>>> somehow publish speculative congestion windows to get rid of slow start in
>>> those cases.
>>> But obviously, none of this is a blocker to shipping this. Just ideas
>>> for winning back some of the losses (that may enable stricter partitioning
>>> if they actually work)
>>>
>>> +Kenji Baheux  - FYI
>>>
>>>

 Explainer:
 https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md

 Review of partitioning design options:
 https://docs.google.com/document/d/1UPjO44CMekDDXIKlih570Z6SOvKQnWzKoDe7APN_GHg/edit

 Blink component

 Internals>Network
 

 TAG review

 https://github.com/w3ctag/design-reviews/issues/596

 TAG review status

 Issues addressed

 Risks
 

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

['Jun Kokatsu' via blink-dev]

On Thu, Jan 12, 2023 at 10:44 AM Mike Taylor  wrote:

> On 1/11/23 6:49 PM, 'Jun Kokatsu' via blink-dev wrote:
>
> Contact emails
>
> jkoka...@google.com
>
> Specification
>
> https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute
>
> https://github.com/w3c/svgwg/pull/901/files
>
> Summary
>
> Assigning a data: URL in SVGUseElement can cause XSS. And this also led to
> a Trusted Types bypass.
>
> Therefore, we plan to deprecate and remove support for it.
>
>
> Blink component
>
> Blink>SVG
> 
>
> Motivation
>
> Assigning an attacker controlled string to SVGUseElement.href causes XSS
> and a Trusted Types bypass
>  because of data: URLs.
> If we fix this bug by requiring TrustedScriptURL assignment to
> SVGUseElement.href under Trusted Types enforcement, many sites would need
> to refactor code (even for same-origin URL or Blob URL assignment).
>
> Since Webkit does not support data: URLs in SVGUseElement and both Mozilla
> and Webkit are supportive for the removal, we think that removing support
> for data: URLs in SVGUseElement is the right way to solve this problem.
>
> Additionally, data: URLs can only trigger script execution in script
> loaders such as HTMLScriptElement.src or dynamic import
> .
> However, SVGUseElement is an exception to this, which also caused a bypass
>  in
> the Sanitizer API. We believe that this also led to several other bugs in
> sanitizers and linters missing a check for this special case.
>
> The usage
>  of
> data: URLs in SVGUseElement is about 0.005%.
>
> Digging into the HTTP Archive shows usages in ~50 sites. There are 2 major
> sites (slickdeals.net and hunter.104.com.tw) which use data: URLs in
> SVGUseElement.
>
> The use in slickdeals.net is invisible (i.e. used in the footer but
> doesn't appear), and hunter.104.com.tw is using it for a single icon in
> the footer (which is already broken when rendered in Webkit). Rest of the
> usages seems to be in individual small sites.
>
> I poked around the 10 sample sites at the bottom of the use counter:
>
> https://www.aspareanord.it/, https://www.umbria.camcom.it,
> https://www.bisenzio.it/, https://www.comune.vernio.po.it/,
> https://appaltinnovativi.gov.it/, https://www.gdf.gov.it/,
> https://www.us.schott.com/, https://shop.wavin.com/, https://jobs.nzz.ch/,
> https://www.learnapp.com/
>
> For the 6 Italian sites (I guess the same agency made them?), the right
> arrow icon next to "Vedi" would disappear. For a site like
> https://jobs.nzz.ch - there's a number of visually significant design
> icons that would be gone towards the bottom (and yes, it looks sort of
> broken today in Safari).
>
> It's not the end of the world, looking at these 10 sites, but I wonder how
> a developer would know how to fix this. Have you considered a DevTools
> issue?
>

Thank you for the suggestion! Yes, I do plan to follow Deprecation steps

and
add a Devtools issue 

> Initial public proposal
>
> TAG review
>
> TAG review status
>
> Not applicable.
>
> Because this intent removes part of a feature, and it is already shipped
> in Webkit (i.e. never supported).
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Positive
> 
>
> WebKit: Positive
> 
>
> Web developers: No signals
>
>
> Debuggability
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes 
>
> Flag name
>
> RemoveDataUrlInSvgUse
>
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1300195
>
> Estimated milestones
>
> Deprecate for 2 milestones, then remove depending on breakages.
>
> Can you say more about what the deprecation looks like (i.e., blog post,
> deprecation reports, devtools issue, etc)?
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5128825141198848
>
> 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
> 

Re: [blink-dev] Intent to Ship: CSS Selectors 4 Pseudo-Class :nth-child(an + b of S)

[Mike Taylor]

On 1/12/23 1:24 PM, Steinar H. Gunderson wrote:

On Thu, Jan 12, 2023 at 01:09:41PM -0500, Mike Taylor wrote:

Gecko: In development

Do you have a link?

https://bugzilla.mozilla.org/show_bug.cgi?id=1808227
Thank you - it looks to be implemented in Nightly, by behind the 
layout.css.nth-child-of.enabled pref for now.

Is this feature fully tested by web-platform-tests?
Yes. (We added more WPT tests as part of implementing it.)

How do we do with the feature enabled, compared to Safari?

We pass all the tests (32 base tests + 8 invalidation tests),
Safari TP fails two of the base tests and four of the invalidation
tests (at least according to wpt.fyi).

/* Steinar */



--
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/b8b15031-b35d-56a1-70b6-d5c76d662155%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS Selectors 4 Pseudo-Class :nth-child(an + b of S)

[Steinar H. Gunderson]

On Thu, Jan 12, 2023 at 01:09:41PM -0500, Mike Taylor wrote:
>> Gecko: In development
> Do you have a link?

https://bugzilla.mozilla.org/show_bug.cgi?id=1808227

>> Is this feature fully tested by web-platform-tests?
>> Yes. (We added more WPT tests as part of implementing it.)
> How do we do with the feature enabled, compared to Safari?

We pass all the tests (32 base tests + 8 invalidation tests),
Safari TP fails two of the base tests and four of the invalidation
tests (at least according to wpt.fyi).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

-- 
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/20230112182415.yk3apmql37en6h5g%40sesse.net.

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

[Mike Taylor]

On 1/11/23 6:49 PM, 'Jun Kokatsu' via blink-dev wrote:



Contact emails

jkoka...@google.com


Specification

https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute 



https://github.com/w3c/svgwg/pull/901/files


Summary

Assigning a data: URL in SVGUseElement can cause XSS. And this also 
led to a Trusted Types bypass.



Therefore, we plan to deprecate and remove support for it.



Blink component

Blink>SVG 




Motivation

Assigning an attacker controlled string to SVGUseElement.href causes 
XSS and a Trusted Types bypass 
because of data: 
URLs. If we fix this bug by requiring TrustedScriptURL assignment to 
SVGUseElement.href under Trusted Types enforcement, many sites would 
need to refactor code (even for same-origin URL or Blob URL assignment).



Since Webkit does not support data: URLs in SVGUseElement and both 
Mozilla and Webkit are supportive for the removal, we think that 
removing support for data: URLs in SVGUseElement is the right way to 
solve this problem.



Additionally, data: URLs can only trigger script execution in script 
loaders such as HTMLScriptElement.src or dynamic import 
. 
However, SVGUseElement is an exception to this, which also caused a 
bypass 
in 
the Sanitizer API. We believe that this also led to several other bugs 
in sanitizers and linters missing a check for this special case.



The usage 
of 
data: URLs in SVGUseElement is about 0.005%.



Digging into the HTTP Archive shows usages in ~50 sites. There are 2 
major sites (slickdeals.net and 
hunter.104.com.tw ) which use data: URLs in 
SVGUseElement.


The use in slickdeals.net is invisible (i.e. 
used in the footer but doesn't appear), and hunter.104.com.tw 
is using it for a single icon in the footer 
(which is already broken when rendered in Webkit). Rest of the usages 
seems to be in individual small sites.



I poked around the 10 sample sites at the bottom of the use counter:

https://www.aspareanord.it/, https://www.umbria.camcom.it, 
https://www.bisenzio.it/, https://www.comune.vernio.po.it/, 
https://appaltinnovativi.gov.it/, https://www.gdf.gov.it/, 
https://www.us.schott.com/, https://shop.wavin.com/, 
https://jobs.nzz.ch/, https://www.learnapp.com/


For the 6 Italian sites (I guess the same agency made them?), the right 
arrow icon next to "Vedi" would disappear. For a site like 
https://jobs.nzz.ch - there's a number of visually significant design 
icons that would be gone towards the bottom (and yes, it looks sort of 
broken today in Safari).


It's not the end of the world, looking at these 10 sites, but I wonder 
how a developer would know how to fix this. Have you considered a 
DevTools issue?




Initial public proposal



TAG review



TAG review status

Not applicable.

Because this intent removes part of a feature, and it is already 
shipped in Webkit (i.e. never supported).



Risks



Interoperability and Compatibility



Gecko: Positive 




WebKit: Positive 




Web developers: No signals



Debuggability



Is this feature fully tested by web-platform-tests

?

Yes 


Flag name

RemoveDataUrlInSvgUse



Requires code in //chrome?

False


Tracking bug

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




Estimated milestones

Deprecate for 2 milestones, then remove depending on breakages.

Can you say more about what the deprecation looks like (i.e., blog post, 
deprecation reports, devtools issue, etc)?



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5128825141198848 




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 

Re: [blink-dev] Intent to Ship: CSS Selectors 4 Pseudo-Class :nth-child(an + b of S)

[Mike Taylor]

Hi Steinar,

On 1/12/23 5:32 AM, Steinar H. Gunderson wrote:

Contact emails: se...@chromium.org
Explainer: None
Specification: https://www.w3.org/TR/selectors-4

Summary:
Extend :nth-child(an + b) to take a selector, and the same with
:nth-last-child. So e.g. :nth-child(3 .c) is the third .c under a given
parent. (This is not the same as .c:nth-child(3), which is a .c that must
also be the third element under a given parent.)

Blink component: Blink>CSS
TAG review status: Not applicable

Risks, Interoperability and Compatibility: None known. Part of Interop 2023.

Gecko: In development

Do you have a link?

WebKit: Shipped/Shipping

WebView application risks: None.
Debuggability: N/A

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?
Yes. (We added more WPT tests as part of implementing it.)

How do we do with the feature enabled, compared to Safari?

Flag name: CSSSelectorNthChildComplexSelectorEnabled

Requires code in //chrome? No

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

Estimated milestones
Shipping on desktop: 111
Shipping on Android: 111

Anticipated spec changes: None.

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

/* Steinar */



--
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/47b0578a-e377-1cd0-946d-d1c794081966%40chromium.org.

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

['Darius Iko' via blink-dev]

Hi Everyone,

Related to this removal of navigation to filesystem URL, there is a release 
notes in 104 probably related: 
https://support.google.com/chrome/a/answer/10314655#108=%2Cchrome:~:text=First%20mode%20feature.-,Block%20iframe%20contexts%20navigating%20to%20filesystem%3A%20URLs,-Beginning%20in%20Chrome

When I am using Chrome OS 104, I see that the webview and iframe tag cannot 
navigate to filesystem URL anymore, and this also happened on 104 105 106 
107, but on Chrome OS 108, the webview and iframe tag can navigate to 
filesystem URL again. Is the navigation to filesystem allowed back on 108 
and above ? May I know how is the future about the behavior of navigation 
to filesystem because I don't see anything related filesystem in the 
release notes of 108 ?

Thanks.

On Friday, September 23, 2022 at 11:42:12 PM UTC+8 mike...@chromium.org 
wrote:

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

Re: [blink-dev] Intent to Ship: CSS Root Font Units: 'rex', 'rch', 'ric', 'rlh'

['Daniil Sakhapov' via blink-dev]

Safari has claimed to implement rlh, but nothing else I guess. None of them
are in Firefox.

On Tue, Jan 10, 2023 at 11:11 AM Philip Jägenstedt 
wrote:

> I see the Gecko issue has now been resolved as positive, which is great.
>
> Are any of these units already supported in Firefox or Safari, or would we
> be the first to ship all of them? (I took a look at one test and have a
> guess, but just as well to ask.)
>
> On Sat, 7 Jan 2023 at 01:48 Mike Taylor  wrote:
>
>> On 1/5/23 5:07 AM, 'Daniil Sakhapov' via blink-dev wrote:
>>
>> Contact emails sakha...@chromium.org
>>
>> Specification https://www.w3.org/TR/css-values-4/#font-relative-lengths
>>
>> Summary
>>
>> Allows usage of root font units. Currently only 'rem' is supported in
>> Blink. This feature supports root element variants of ex, ch, ic, and lh
>> too.
>>
>> Blink component Blink>CSS
>> 
>>
>> Search tags rlh , ric
>> , rch
>> , rex
>> , root font
>> 
>>
>> TAG review The feature is not fundamental and only implements an
>> existing standard
>>
>> Note that CSS Values and Units Level 4 is not yet a standard, but a working
>> draft .
>>
>> That said, it seems the TAG recently reviewed the draft spec and was
>> satisfied with it:
>>
>> https://github.com/w3ctag/design-reviews/issues/781
>>
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/725)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/112)
>>
>> *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
>>
>> The new units should be automatically supported by devtools. No need for
>> any changes.
>>
>> 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
>> 
>> ? Yes
>> https://wpt.fyi/css/css-values/rlh-invalidation.html
>> https://wpt.fyi/css/css-values/ric-invalidation.html
>> https://wpt.fyi/css/css-values/rch-invalidation.html
>> https://wpt.fyi/css/css-values/rex-invalidation.html
>> https://wpt.fyi/css/css-values/lh-rlh-on-root-001.html
>>
>> https://wpt.fyi/css/css-typed-om/stylevalue-subclasses/numeric-objects/cssUnitValue.html
>> https://wpt.fyi/css/css-contain/container-queries/font-relative-units.html
>>
>> https://wpt.fyi/css/css-contain/container-queries/font-relative-units-dynamic.html
>>
>> Flag name #enable-experimental-web-platform-features /
>> CSSNewRootFontUnits (Blink)
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1381037
>>
>> Estimated milestones
>> DevTrial on desktop 111
>> DevTrial on Android 111
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5073969265246208
>> --
>> 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/CAK_fkKV3D8Gpno7mie4LD5B%2BNiGvjfnRvAtJ5rsiBWYL8Mv2Bw%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/925d0226-4c69-1c28-13b1-59854c1617ca%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 

[blink-dev] Intent to Ship: CSS Selectors 4 Pseudo-Class :nth-child(an + b of S)

[Steinar H. Gunderson]

Contact emails: se...@chromium.org
Explainer: None
Specification: https://www.w3.org/TR/selectors-4

Summary:
Extend :nth-child(an + b) to take a selector, and the same with
:nth-last-child. So e.g. :nth-child(3 .c) is the third .c under a given
parent. (This is not the same as .c:nth-child(3), which is a .c that must
also be the third element under a given parent.)

Blink component: Blink>CSS
TAG review status: Not applicable

Risks, Interoperability and Compatibility: None known. Part of Interop 2023.

Gecko: In development
WebKit: Shipped/Shipping

WebView application risks: None.
Debuggability: N/A

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?
Yes. (We added more WPT tests as part of implementing it.)

Flag name: CSSSelectorNthChildComplexSelectorEnabled

Requires code in //chrome? No

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

Estimated milestones
Shipping on desktop: 111
Shipping on Android: 111

Anticipated spec changes: None.

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

/* Steinar */
-- 
Software Engineer, Google Norway

-- 
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/20230112103247.dlep4m4lsdr5haxa%40sesse.net.

Re: [blink-dev] Re: Intent to Ship: WebGPU

['Ashley Gullen' via blink-dev]

OK thanks - it's just at the moment it's not clear if extensions aren't
supported due to missing implementation (so it won't work anywhere), or an
unsupported system (in which case I can potentially get it working and test
my code if I find the right system setup). Extra visibility on that would
be good.

- Ashley

On Thu, 12 Jan 2023 at 12:21, Corentin Wallez  wrote:

> Hey Ashley,
>
> Happy to talk in more detail outside of the I2S thread. In general WebGPU
> optional features are optional as they can depend on hardware capabilities.
> The only guarantee is that around texture compression where the following
> must be true: BC || (ETC2 && ASTC). For shader-float16 for example, we are
> planning to have it implemented around the V1 timeframe, but it can't be
> universal as it depends on hardware capabilities and platform compiler
> support (which is the blocking part of your setup). For F16 one solution to
> bridge availability is to use type aliases: you can do `type maybe_f16 =
> f16;` or the same with f32 and use `maybe_f16` everywhere.
>
> Hopefully this helps, but in general after V1 we should have a clear
> roadmap to give visibility to the ecosystem.
>
> Cheers,
>
> Corentin
>
> On Thu, Jan 12, 2023 at 11:55 AM Ashley Gullen  wrote:
>
>> Can I ask what the release schedule is for the various WebGPU extensions
>> as well? It's not currently clear to me which extensions are planned to be
>> shipped with the first release of WebGPU and which are to be implemented
>> later down the line.
>>
>> As of today's Canary 111.0.5534.0 on Windows 11 with a nVidia GeForce GTX
>> 1070, I can see the following adapter features: indirect-first-instance,
>> texture-compression-bc, depth32float-stencil8, rg11b10ufloat-renderable
>> However the current spec's feature index lists 5 other extensions,
>> notably including shader-f16 and timestamp-query. I'm particularly
>> interested in the status of shader-f16, as our product allows for
>> third-party shaders, and I want to avoid any backwards compatibility
>> complications if it's introduced later down the line. But I'm also not
>> clear if the OS/hardware combo is meant to support this too.
>>
>> As a WebGPU developer it would be useful to see official documentation
>> somewhere of the individual development/shipping status for each WebGPU
>> extension.
>>
>> Thanks for all the great work on WebGPU!
>>
>>
>> On Wed, 11 Jan 2023 at 17:57, Corentin Wallez 
>> wrote:
>>
>>> Thank you everyone for the LGTMs!
>>>
>>> We're super excited to get a high-quality WebGPU implementation in
>>> developer's hands! The list of issues we are tracking on the implementation
>>> side are
>>> 
>>> these
>>> 
>>> three
>>> 
>>>  (for
>>> the three parts that make WebGPU) and we expect to fix most issues before
>>> shipping, with clear rational of why the ones that aren't can be delayed.
>>> Of course we expect to find new issues as we keep expanding the test suite
>>> but will add them to the bug trackers I just linked for V1 tracking as well.
>>>
>>> On Wednesday, January 11, 2023 at 6:18:17 PM UTC+1 Yoav Weiss wrote:
>>>
 LGTM3

 On Wed, Jan 11, 2023 at 6:06 PM Rick Byers  wrote:

> We discussed in the API owner meeting and agree that we are impressed
> with all the work that's gone into interoperability here and the broad
> general support across implementers. We have high confidence that the team
> is setting an appropriately high quality bar both for shipping and for
> ongoing updates and interoperability improvements post-ship. So LGTM2 to
> ship whenever the team feels it's ready.
>
> This feature has been a long time in the making and I'm excited to see
> it launch ASAP, great work!
>
> Rick
>
> On Wed, Jan 11, 2023 at 11:52 AM slightlyoff via Chromestatus <
> admin+slightly...@cr-status.appspotmail.com> wrote:
>
>> An enthusiastic LGTM1 from me. Congrats on getting to this point; a
>> big moment.
>>
>> --
>> 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/4c1db705f1ffd237%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 

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

[Rune Lillesveen]

On Thu, Jan 12, 2023 at 1:00 PM Yoav Weiss  wrote:

>
>
> On Wed, Jan 11, 2023 at 7:53 AM Yoav Weiss  wrote:
>
>> thanks! :)
>>
>> On Wed, Jan 11, 2023 at 6:42 AM Byungwoo Lee  wrote:
>>
>>> Something wrong with the citation style of the previous mail. I'll send
>>> the reply again.
>>>
>>> >>> OK, so for where we're risking seeing more fallbacks than before,
>>> but according to your manual inspection, that seems fine?
>>> >> Yes, I think so.
>>> >> Based on the usage metrics, only about 0.5 % of page loads could be
>>> affected by this feature.
>>>
>>
> Just to clarify - 0.5% is about 2 orders of magnitude higher than the
> levels of breakage we're typically comfortable with.
> But from our discussion it seems that the levels of actual breakage are
> likely to be significantly smaller.
>
> Considering the manual investigation on the top pages (only 1 of of 10 is
>>> for `:where()`, and the rest are for `:has()`. no urls for `:is()`), the
>>> ratio of the `:where()` is likely to be much less than 0.5 %.
>>> > In the manual inspection, how many function calls had a mix of valid
>>> and invalid selectors? (that would be impacted by this change)
>>> There is no mix of valid and invalid in the manual inspection for the
>>> top URLs. :has() and :where() are used only with empty argument or valid
>>> argument.
>>>
>>>
>>> >> Will it be better to add a feature for this change and add some
>>> metrics (something like, how many page loads use :has() with both valid and
>>> invalid selector) before releasing it to stable?
>>> > Adding a feature (including a base_feature) to the `:has` change would
>>> be good. Would you be able to merge that back to 110?
>>> > I think we should tie the `:has` change to this intent. The risk
>>> profile seems similar.
>>> I made a CL that adds 'CSSPseudoHasNonForgivingParsing' feature (
>>> https://chromestatus.com/feature/6177049203441664) for the change:
>>> - https://chromium-review.googlesource.com/c/chromium/src/+/4151453
>>>
>>> The CL also adds two metrics so that we can get usecounter of the cases
>>> that the change affects:
>>> - CSSPseudoHasContainsMixOfValidAndInvalid : ':has(a, :foo)'
>>> - CSSPseudoIsWhereContainsMixOfValidAndInvalid : ':is(a, :foo)',
>>> ':where(a, :foo)'
>>>
>>>  I'll try to merge the CL to 110 branch after it landed.
>>>
>>
> That'd be great to land and merge back.
> +Rune Lillesveen  - can you help make that happen?
>

Yes.

Once we have that in place, I'd be comfortable with turning on the feature
> on M111, and carefully watching the (internal) UMA use counter stats for
> Beta as it rolls out, and revert it if we'd see that actual breakage is
> likely to be larger than expected.
>
> Rune, Byungwoo - what do you think?
>

Sgtm.


>
>>>
>>> 2023년 1월 11일 수요일 오후 2시 33분 10초 UTC+9에 Byungwoo Lee님이 작성:
>>>


 2023년 1월 9일 월요일 오후 7시 36분 34초 UTC+9에 yoav...@chromium.org님이 작성:
 On Mon, Jan 9, 2023 at 11:12 AM Byungwoo Lee  wrote:
 Thanks! I replied again. :)

 2023년 1월 6일 금요일 오후 7시 50분 43초 UTC+9에 yoav...@chromium.org님이 작성:
 On Thu, Jan 5, 2023 at 4:59 PM Byungwoo Lee  wrote:
 Added missing links.

 2023년 1월 6일 금요일 오전 12시 52분 25초 UTC+9에 Byungwoo Lee님이 작성:

 Thanks for asking!


 > Is this change covered by a base feature flag?

 This is behind 'CSSAtSupportsAlwaysNonForgivingParsing' flag, and the
 flag doesn't have 'base_feature' field yet. I'll add the field to the
 feature before enable it.


 > Can you clarify if the ':has()' behavior will change here or not?
 This last sentence seems to contradict the original message of the intent.

 > Can you confirm that both these cases won't break?

 There's a bit of twisted history here, so it would be better to answer
 these two questions at once. (Sorry for the long answer!)


 1. What can this feature change?

 After this feature enabled, `@supports selector()` can return different
 result when it checks forgiving-parsing pseudo class.

 For example, `@supports selector(:where(:foo, a))` returns true now
 (forgiving parsing drops invalid `:foo` inside `:where()`, so the
 `:where(:foo, a)` becomes a valid selector `:where(a)` after forgiving
 parsing), but it will return false after this feature enabled
 (`:where(:foo, a)` will be invalid inside `@supports selector()`).

 OK, so for where we're risking seeing more fallbacks than before, but
 according to your manual inspection, that seems fine?

 Yes, I think so.
 Based on the usage metrics, only about 0.5 % of page loads could be
 affected by this feature. Considering the manual investigation on the top
 pages (only 1 of of 10 is for `:where()`, and the rest are for `:has()`. no
 urls for `:is()`), the ratio of the `:where()` is likely to be much less
 than 0.5 %.

 In the manual inspection, how many function calls had a mix of valid
 and invalid 

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

[Mike Taylor]

Hi Darius,

In https://bugs.chromium.org/p/chromium/issues/detail?id=1360512, this 
feature was re-enabled for Chrome Apps only (as we unfortunately broke 
some apps in that context :(). This feature should continue to work 
until Chrome Apps are removed 
.


thanks,
Mike

On 1/12/23 4:19 AM, Darius Iko wrote:

Hi Everyone,

Related to this removal of navigation to filesystem URL, there is a 
release notes in 104 probably related: 
https://support.google.com/chrome/a/answer/10314655#108=%2Cchrome:~:text=First%20mode%20feature.-,Block%20iframe%20contexts%20navigating%20to%20filesystem%3A%20URLs,-Beginning%20in%20Chrome


When I am using Chrome OS 104, I see that the webview and iframe tag 
cannot navigate to filesystem URL anymore, and this also happened on 
104 105 106 107, but on Chrome OS 108, the webview and iframe tag can 
navigate to filesystem URL again. Is the navigation to filesystem 
allowed back on 108 and above ? May I know how is the future about the 
behavior of navigation to filesystem because I don't see anything 
related filesystem in the release notes of 108 ?


Thanks.

On Friday, September 23, 2022 at 11:42:12 PM UTC+8 
mike...@chromium.org wrote:


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%

Re: [blink-dev] Re: Intent to Ship: WebGPU

[Corentin Wallez]

Hey Ashley,

Happy to talk in more detail outside of the I2S thread. In general WebGPU
optional features are optional as they can depend on hardware capabilities.
The only guarantee is that around texture compression where the following
must be true: BC || (ETC2 && ASTC). For shader-float16 for example, we are
planning to have it implemented around the V1 timeframe, but it can't be
universal as it depends on hardware capabilities and platform compiler
support (which is the blocking part of your setup). For F16 one solution to
bridge availability is to use type aliases: you can do `type maybe_f16 =
f16;` or the same with f32 and use `maybe_f16` everywhere.

Hopefully this helps, but in general after V1 we should have a clear
roadmap to give visibility to the ecosystem.

Cheers,

Corentin

On Thu, Jan 12, 2023 at 11:55 AM Ashley Gullen  wrote:

> Can I ask what the release schedule is for the various WebGPU extensions
> as well? It's not currently clear to me which extensions are planned to be
> shipped with the first release of WebGPU and which are to be implemented
> later down the line.
>
> As of today's Canary 111.0.5534.0 on Windows 11 with a nVidia GeForce GTX
> 1070, I can see the following adapter features: indirect-first-instance,
> texture-compression-bc, depth32float-stencil8, rg11b10ufloat-renderable
> However the current spec's feature index lists 5 other extensions, notably
> including shader-f16 and timestamp-query. I'm particularly interested in
> the status of shader-f16, as our product allows for third-party shaders,
> and I want to avoid any backwards compatibility complications if it's
> introduced later down the line. But I'm also not clear if the OS/hardware
> combo is meant to support this too.
>
> As a WebGPU developer it would be useful to see official documentation
> somewhere of the individual development/shipping status for each WebGPU
> extension.
>
> Thanks for all the great work on WebGPU!
>
>
> On Wed, 11 Jan 2023 at 17:57, Corentin Wallez 
> wrote:
>
>> Thank you everyone for the LGTMs!
>>
>> We're super excited to get a high-quality WebGPU implementation in
>> developer's hands! The list of issues we are tracking on the implementation
>> side are
>> 
>> these
>> 
>> three
>> 
>>  (for
>> the three parts that make WebGPU) and we expect to fix most issues before
>> shipping, with clear rational of why the ones that aren't can be delayed.
>> Of course we expect to find new issues as we keep expanding the test suite
>> but will add them to the bug trackers I just linked for V1 tracking as well.
>>
>> On Wednesday, January 11, 2023 at 6:18:17 PM UTC+1 Yoav Weiss wrote:
>>
>>> LGTM3
>>>
>>> On Wed, Jan 11, 2023 at 6:06 PM Rick Byers  wrote:
>>>
 We discussed in the API owner meeting and agree that we are impressed
 with all the work that's gone into interoperability here and the broad
 general support across implementers. We have high confidence that the team
 is setting an appropriately high quality bar both for shipping and for
 ongoing updates and interoperability improvements post-ship. So LGTM2 to
 ship whenever the team feels it's ready.

 This feature has been a long time in the making and I'm excited to see
 it launch ASAP, great work!

 Rick

 On Wed, Jan 11, 2023 at 11:52 AM slightlyoff via Chromestatus <
 admin+slightly...@cr-status.appspotmail.com> wrote:

> An enthusiastic LGTM1 from me. Congrats on getting to this point; a
> big moment.
>
> --
> 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/4c1db705f1ffd237%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/CAFUtAY98ckLv_13k9sBxQfDC%3DtDyqPA9_hLOMiVG4Fn4%2B9njwQ%40mail.gmail.com
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To 

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

[Yoav Weiss]

On Wed, Jan 11, 2023 at 7:53 AM Yoav Weiss  wrote:

> thanks! :)
>
> On Wed, Jan 11, 2023 at 6:42 AM Byungwoo Lee  wrote:
>
>> Something wrong with the citation style of the previous mail. I'll send
>> the reply again.
>>
>> >>> OK, so for where we're risking seeing more fallbacks than before, but
>> according to your manual inspection, that seems fine?
>> >> Yes, I think so.
>> >> Based on the usage metrics, only about 0.5 % of page loads could be
>> affected by this feature.
>>
>
Just to clarify - 0.5% is about 2 orders of magnitude higher than the
levels of breakage we're typically comfortable with.
But from our discussion it seems that the levels of actual breakage are
likely to be significantly smaller.

Considering the manual investigation on the top pages (only 1 of of 10 is
>> for `:where()`, and the rest are for `:has()`. no urls for `:is()`), the
>> ratio of the `:where()` is likely to be much less than 0.5 %.
>> > In the manual inspection, how many function calls had a mix of valid
>> and invalid selectors? (that would be impacted by this change)
>> There is no mix of valid and invalid in the manual inspection for the top
>> URLs. :has() and :where() are used only with empty argument or valid
>> argument.
>>
>>
>> >> Will it be better to add a feature for this change and add some
>> metrics (something like, how many page loads use :has() with both valid and
>> invalid selector) before releasing it to stable?
>> > Adding a feature (including a base_feature) to the `:has` change would
>> be good. Would you be able to merge that back to 110?
>> > I think we should tie the `:has` change to this intent. The risk
>> profile seems similar.
>> I made a CL that adds 'CSSPseudoHasNonForgivingParsing' feature (
>> https://chromestatus.com/feature/6177049203441664) for the change:
>> - https://chromium-review.googlesource.com/c/chromium/src/+/4151453
>>
>> The CL also adds two metrics so that we can get usecounter of the cases
>> that the change affects:
>> - CSSPseudoHasContainsMixOfValidAndInvalid : ':has(a, :foo)'
>> - CSSPseudoIsWhereContainsMixOfValidAndInvalid : ':is(a, :foo)',
>> ':where(a, :foo)'
>>
>>  I'll try to merge the CL to 110 branch after it landed.
>>
>
That'd be great to land and merge back.
+Rune Lillesveen  - can you help make that happen?

Once we have that in place, I'd be comfortable with turning on the feature
on M111, and carefully watching the (internal) UMA use counter stats for
Beta as it rolls out, and revert it if we'd see that actual breakage is
likely to be larger than expected.

Rune, Byungwoo - what do you think?


>>
>> 2023년 1월 11일 수요일 오후 2시 33분 10초 UTC+9에 Byungwoo Lee님이 작성:
>>
>>>
>>>
>>> 2023년 1월 9일 월요일 오후 7시 36분 34초 UTC+9에 yoav...@chromium.org님이 작성:
>>> On Mon, Jan 9, 2023 at 11:12 AM Byungwoo Lee  wrote:
>>> Thanks! I replied again. :)
>>>
>>> 2023년 1월 6일 금요일 오후 7시 50분 43초 UTC+9에 yoav...@chromium.org님이 작성:
>>> On Thu, Jan 5, 2023 at 4:59 PM Byungwoo Lee  wrote:
>>> Added missing links.
>>>
>>> 2023년 1월 6일 금요일 오전 12시 52분 25초 UTC+9에 Byungwoo Lee님이 작성:
>>>
>>> Thanks for asking!
>>>
>>>
>>> > Is this change covered by a base feature flag?
>>>
>>> This is behind 'CSSAtSupportsAlwaysNonForgivingParsing' flag, and the
>>> flag doesn't have 'base_feature' field yet. I'll add the field to the
>>> feature before enable it.
>>>
>>>
>>> > Can you clarify if the ':has()' behavior will change here or not? This
>>> last sentence seems to contradict the original message of the intent.
>>>
>>> > Can you confirm that both these cases won't break?
>>>
>>> There's a bit of twisted history here, so it would be better to answer
>>> these two questions at once. (Sorry for the long answer!)
>>>
>>>
>>> 1. What can this feature change?
>>>
>>> After this feature enabled, `@supports selector()` can return different
>>> result when it checks forgiving-parsing pseudo class.
>>>
>>> For example, `@supports selector(:where(:foo, a))` returns true now
>>> (forgiving parsing drops invalid `:foo` inside `:where()`, so the
>>> `:where(:foo, a)` becomes a valid selector `:where(a)` after forgiving
>>> parsing), but it will return false after this feature enabled
>>> (`:where(:foo, a)` will be invalid inside `@supports selector()`).
>>>
>>> OK, so for where we're risking seeing more fallbacks than before, but
>>> according to your manual inspection, that seems fine?
>>>
>>> Yes, I think so.
>>> Based on the usage metrics, only about 0.5 % of page loads could be
>>> affected by this feature. Considering the manual investigation on the top
>>> pages (only 1 of of 10 is for `:where()`, and the rest are for `:has()`. no
>>> urls for `:is()`), the ratio of the `:where()` is likely to be much less
>>> than 0.5 %.
>>>
>>> In the manual inspection, how many function calls had a mix of valid and
>>> invalid selectors? (that would be impacted by this change)
>>> There is no mix of valid and invalid in the manual inspection for the
>>> top URLs. :has() and :where() are used only with empty argument or valid
>>> 

Re: [blink-dev] Re: Intent to Ship: WebGPU

['Ashley Gullen' via blink-dev]

Can I ask what the release schedule is for the various WebGPU extensions as
well? It's not currently clear to me which extensions are planned to be
shipped with the first release of WebGPU and which are to be implemented
later down the line.

As of today's Canary 111.0.5534.0 on Windows 11 with a nVidia GeForce GTX
1070, I can see the following adapter features: indirect-first-instance,
texture-compression-bc, depth32float-stencil8, rg11b10ufloat-renderable
However the current spec's feature index lists 5 other extensions, notably
including shader-f16 and timestamp-query. I'm particularly interested in
the status of shader-f16, as our product allows for third-party shaders,
and I want to avoid any backwards compatibility complications if it's
introduced later down the line. But I'm also not clear if the OS/hardware
combo is meant to support this too.

As a WebGPU developer it would be useful to see official documentation
somewhere of the individual development/shipping status for each WebGPU
extension.

Thanks for all the great work on WebGPU!


On Wed, 11 Jan 2023 at 17:57, Corentin Wallez  wrote:

> Thank you everyone for the LGTMs!
>
> We're super excited to get a high-quality WebGPU implementation in
> developer's hands! The list of issues we are tracking on the implementation
> side are
> 
> these
> 
> three
> 
>  (for
> the three parts that make WebGPU) and we expect to fix most issues before
> shipping, with clear rational of why the ones that aren't can be delayed.
> Of course we expect to find new issues as we keep expanding the test suite
> but will add them to the bug trackers I just linked for V1 tracking as well.
>
> On Wednesday, January 11, 2023 at 6:18:17 PM UTC+1 Yoav Weiss wrote:
>
>> LGTM3
>>
>> On Wed, Jan 11, 2023 at 6:06 PM Rick Byers  wrote:
>>
>>> We discussed in the API owner meeting and agree that we are impressed
>>> with all the work that's gone into interoperability here and the broad
>>> general support across implementers. We have high confidence that the team
>>> is setting an appropriately high quality bar both for shipping and for
>>> ongoing updates and interoperability improvements post-ship. So LGTM2 to
>>> ship whenever the team feels it's ready.
>>>
>>> This feature has been a long time in the making and I'm excited to see
>>> it launch ASAP, great work!
>>>
>>> Rick
>>>
>>> On Wed, Jan 11, 2023 at 11:52 AM slightlyoff via Chromestatus <
>>> admin+slightly...@cr-status.appspotmail.com> wrote:
>>>
 An enthusiastic LGTM1 from me. Congrats on getting to this point; a big
 moment.

 --
 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/4c1db705f1ffd237%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/CAFUtAY98ckLv_13k9sBxQfDC%3DtDyqPA9_hLOMiVG4Fn4%2B9njwQ%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/7e739536-1bef-4bee-a44a-d2350ab79f3fn%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/CAABs73jRyQEtk3SdxwEPWMgFwsWvOQXapC%3Dh799JB9a16bt6SA%40mail.gmail.com.