[blink-dev] Intent to Prototype: "deflate-raw" compression format

[Yutaka Hirano]

Contact emailsyhir...@chromium.org, ri...@chromium.org

ExplainerNone

Specificationhttps://wicg.github.io/compression/
https://github.com/WICG/compression/pull/43

Summary

Add a new compression format, "deflate-raw", to give web developers to
access to the raw deflate stream without any headers or footers. This is
needed, for example, to read/write zip files.

Blink componentBlink>Network>StreamsAPI


Motivation

To allow web developers to handle raw deflate stream without any headers or
footers.


Initial public proposalhttps://github.com/WICG/compression/issues/25

TAG reviewTAG review status
N/A, I believe this is subtle enough to skip TAG review.

Risks


Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/wicg/compression/issues/25)

Other signals:

WebView application risks



Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag name#enable-experimental-web-platform-features

Requires code in //chrome?False

Tracking bughttps://crbug.com/1271220

Estimated milestones

No milestones specified


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

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/CABihn6GYcF5VsvfgEDpYL0rCvxQV9phxwFtJ-FxbTEbqPtJxbg%40mail.gmail.com.

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

['Joshua Bell' via blink-dev]

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

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


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

> On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss  wrote:
>
>> Also, any learnings/feedback from the Origin Trial?
>>
>>
> Not distinct from the dev trial (i.e. developers trying the API behind a
> flag). There was a feature request for additional metadata which was
> implemented, then the request was withdrawn so that code was backed out.
> Other requests are marked as "enhancements" in the issue tracker, e.g. font
> modification timestamps.
>
>
>> On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote:
>>
>>> On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote:
>>>
 Contact emails

 ds...@chromium.org, jsb...@chromium.org

 Explainer

 https://github.com/WICG/local-font-access

 Specification

 https://wicg.github.io/local-font-access/

 Design docsDesign Doc: https://bit.ly/2HWBOLi
 

 Blog: https://web.dev/local-fonts/


 Summary

 Gives web applications the ability to enumerate local fonts and some
 metadata about each. Today, no API exists to provide a list of local fonts
 to web applications.

 Also gives web applications access to the font data as a binary blob,
 allowing those fonts to be rendered within their applications using custom
 text stacks.

 Blink component

 Blink>Fonts
 

 TAG review

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

 TAG review status

 Pending

 RisksInteroperability and Compatibility

 This API has been designed to support feature detection to allow
 applications to gracefully degrade based on the capabilities different user
 agents offer.

 We expect developers using this API to design their web applications to
 use web-based fonts as the primary set of font choices, but allow users to
 opt-in to take advantage of their local fonts for specific design needs.

 If this feature were removed from the platform, web applications would
 lose the ability to enumerate local fonts and retrieve font data but
 otherwise are expected to continue to function.

 Gecko: https://github.com/mozilla/standards-positions/issues/401

>>>
>>> https://github.com/WICG/local-font-access/issues/20 and
>>> https://github.com/WICG/local-font-access/issues/19 are still open and
>>> seem to be increasing the interop risk here. Can you expand on plans to
>>> resolve them?
>>>
>>
> https://github.com/WICG/local-font-access/issues/81 is also related and
> comes down to: how much do we shield the web app from the contents of font
> files? At one extreme, the data is normalized into some strict subset,
> stripping features. At the other, they are treated like files. When we
> started exploring the API we started in the middle exposing the font data
> in a more structured way (e.g. tables), but this (1) would lock the API
> into current font formats/concepts and (2) all sites planning to use the
> API are using common libraries that consume entire files, which already
> have robust parsing. So we lean heavily into the "treat them like files" -
> provide the data and get out of the way of the sites/libraries to use the
> rich data, similar to uploading images.
>
> The API shape takes an options object, which would allow adding a filter
> for font file formats in the future, e.g. {accept: ["font/ttf", "font/off",
> "font/woff", "font/woff2"]}, so that sites could limit what types are
> provided. I could imagine us adding that and providing a default like the
> above if new formats become supported by the web but that might "surprise"
> sites.
>
>
>>
>>>
 WebKit:
 https://lists.webkit.org/pipermail/webkit-dev/2022-April/032176.html

 Web developers: Strongly positive (https://crbug.com/535764#c2) Very
 positive support from web applications that interact with local fonts, such
 as Figma.

 Adopted by: Boxy SVG 


 Other signals:

 Ergonomics

 The feature builds both enumeration and data access into the same new
 API. Separation was considered but rejected. (See the Explainer for more
 details.) That may li

Re: [blink-dev] Intent to Ship: File Handling

['Ajay Rahatekar' via blink-dev]

+ Ajay Rahatekar

On Monday, April 18, 2022 at 9:27:45 AM UTC-7 Chris Harrelson wrote:

> On Mon, Apr 18, 2022 at 9:21 AM Evan Stade  wrote:
>
>> On Fri, Apr 15, 2022 at 3:03 PM Chris Harrelson  
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 15, 2022 at 1:47 PM Evan Stade  wrote:
>>>
 Contact emails

 est...@chromium.org, dmu...@chromium.org

 Explainer

 https://github.com/WICG/file-handling/blob/master/explainer.md

 Specification


 https://wicg.github.io/manifest-incubations/index.html#file_handlers-member

 Design docs

 https://tinyurl.com/file-handling-design

 Summary

 File Handling provides a way for web applications to declare the 
 ability to handle files with given MIME types and extensions. The web 
 application will receive an event when the user intends to open a file 
 with 
 that web application.


 Blink component

 UI>Browser>WebAppInstalls>FileHandling 
 

 Search tags

 files , file handling 
 , mime 
 

 TAG review

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

>>>
>>> The review performed was an early one almost 2 years ago. I've reopened 
>>> this issue so that the TAG can provide a full review.
>>>  
>>>

 TAG review status

 Issues addressed

 Link to origin trial feedback summary


 https://plx.corp.google.com/scripts2/script_61._146b85__2bae_bb88_001a114abbb8

 Risks

 Interoperability and CompatibilityFails to become an interoperable 
 part of the web if other browsers don't implement it.

 Sites can detect whether the feature exists, but polyfill or other 
 fallbacks are unlikely to be possible or required. As this API is just one 
 way to open a file in an app, apps will be able to open files with 
 alternate means (such as  or drag and drop) regardless 
 of the presence of this API.


 Gecko: N/A (https://github.com/mozilla/standards-positions/issues/629)

 WebKit: N/A (
 https://lists.webkit.org/pipermail/webkit-dev/2022-April/032185.html)

 Web developers: Positive (
 https://discourse.wicg.io/t/proposal-ability-to-register-file-handlers/3084/4)
  
 Already being prototyped by at least construct.net and excalidraw.com, 
 based on https://crbug.com/1126091 and https://crbug.com/1131445. We 
 also have a major partner that we can't publicly disclose.

 Other signals:

 Ergonomics

 This feature relies on File System Access and the new 
 LaunchQueue/LaunchHandler objects which are also to be used for 
 `launch_handler`. No known performance risks.


 Activation

 Documentation and outreach will be helpful to understanding this API: 
 https://web.dev/file-handling/


 Security

 Please see the security model: 
 https://docs.google.com/document/d/1pTTO5MTSlxuqxpWL3pFblKB8y8SR0jPao8uAjJSUTp4/edit


 WebView application risks

 Does this intent deprecate or change behavior of existing APIs, such 
 that it has potentially high risk for Android WebView-based applications?

 n/a (not a WebView feature)

>>>
>>> Please make sure this feature is explicitly disabled on WebView.
>>>
>>
>> Certainly. Is there a standard way of doing that, or can we keep on 
>> relying on the feature flag?
>>
>
> Here  
> is one example; it does require a bit of code on top of a Blink 
> RuntimeEnabledFeature.
>  
>
>>  
>>
>>>  
>>>


 Debuggability

 File handlers are shown along with the rest of the manifest in the 
 developer console in the "application" tab. Parsing errors are surfaced 
 there.


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

 Yes

 Flag name

 #file-handling-api

 Requires code in //chrome?

 False

 Tracking bug

 https://crbug.com/829689

 Launch bug

 https://crbug.com/1284364

 Non-OSS dependencies

 Does the feature depend on any code or APIs outside the Chromium open 
 source repository and its open-source dependencies to function?

 n/a

 Sample links

 https://principled-ring-yarrow.glitch.me/

 Estimated milestones

 OriginTrial last

 94

 OriginTrial first

 92

 DevTrial

 92

 Launch

 102


 Anticipat

[blink-dev] Intend to extend experiment: User-Agent Reduction

[Ali Beyad]

Note: please see the “Experiment Timeline” section for our extension
request - the rest of the details are the same as before.

Contact emails

abe...@chromium.org, miketa...@chromium.org
Original I2E

https://groups.google.com/a/chromium.org/g/blink-dev/c/R0xKm1B7qoQ/

Explainer

https://developer.chrome.com/blog/user-agent-reduction-origin-trial/

Specification

None, but we intend to specify the reduced UA in
https://compat.spec.whatwg.org/#ua-string-section as it ships.

Summary

We want to reduce the amount of information the User Agent string exposes
in HTTP requests as well as in navigator.userAgent, navigator.appVersion,
and navigator.platform. The browser's brand and significant version, its
desktop/mobile distinction and the platform it is running on will continue
to be sent.

We would like to run an Origin Trial for sites to opt into the Reduced
User-Agent (and related navigator properties) to proactively test for
breakage. See below for more details.

Design Doc

https://docs.google.com/document/d/1feIxK9S7oNgT2oGGebbxE9X0O-4wTKcsP_gRaY99tq4/edit#heading=h.2navvbygwxwb


Blink component

Blink 

TAG review

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

TAG review status

Closed as “Satisfied with concerns” (
https://github.com/w3ctag/design-reviews/issues/640)

Risks: Interoperability and Compatibility

The compatibility risk is low, as we’re planning to reduce the amount of
information in the UA string, rather than remove the header. Most existing
UA detection code should continue to work. It is only future UA detection
code that will need to move to use the UA client hints instead. In the long
term, we expect this change to improve compatibility, as UA detection based
on UA-CH is bound to be more reliable than the current status quo. We hope
this Origin Trial will help us flesh out site compat issues we can’t
predict a priori.

As for interoperability, other vendors are on board with UA information
reduction, but not necessarily with the UA Client Hints mechanism that is
supposed to replace it. That can create a tricky situation, where
developers would need to rely on the User-Agent string for some browsers
and on UA-CH for others.

Edge: Positive signals (
https://twitter.com/_scottlow/status/1206831008261132289)

Firefox: Public support for reducing UA string information - “freezing the
User Agent string without any client hints—seems worth-prototyping” (from
https://github.com/mozilla/standards-positions/issues/202#issuecomment-558294095
)

Safari: Shipped to some extent. Safari has attempted to completely freeze
the UA string
 in the
past, but somewhat reverted that decision
. Nowadays, their UA
string seems mostly frozen, with updates only to the browser version.

Web developers: Mixed signals. Some positive comments on Twitter,
blink-dev, etc., as well as some negative sentiment.

Experiment Summary

This experiment is going to be a bit different from a normal Origin Trial;
the goal is less about gathering information on the design of a new API
than it is about enabling developers and administrators to test and ensure
compatibility with our proposed changes. This change represents a large
compat challenge with very subtle pitfalls and vast dependencies, it’s
incredibly important we give developers any opportunity to test systems at
every level.

As for engaging with the trial itself, there will be two components
controlled by the same Origin Trial:

   1.

   Reducing the information in the associated JS getters, if the Origin
   Trial is enabled.
   2.

   A client hint that gets set when the Origin Trial is enabled, where the
   client hint indicates to the origin that the User-Agent request header
   contains the reduced value. Because of the experimental nature of this
   client hint, a valid Origin Trial token must be sent in the response header
   by the origin for the client hint to take effect or be stored (in order to
   prevent platform burn-in for this temporary client hint token).


During the process of conducting the Origin Trial, we may find that we need
to request an exception to the per-site (and possibly global) limits
imposed by Origin Trials. In practice, Origin Trials rarely exceed their
quota limits, but if necessary, there is time between when the limits have
been exceeded and the Origin Trial is turned off, where we can work with
the users on reducing their usage and/or lifting the limits.

Please see the design document

describing the experiment for more information.

Experiment Goals

The goal of this trial is to enable developers to test how reducing the
User-Agent request header and the related navigator getters will affect
their systems and make sure they have al

[blink-dev] Intent to Prototype: Isolated Web Apps

[Reilly Grant]

Contact emails

reil...@chromium.org, pjmclach...@chromium.org

Explainer

https://github.com/reillyeon/isolated-web-apps/blob/main/README.md

Specification

Still at the explainer stage.

Summary

Isolated Web Apps extend Progressive Web App
 installation and Web Packaging to
provide stronger protection against server compromise and other tampering.
A small set of security-sensitive applications require this to migrate from
Chrome Apps, Electron, or other web-adjacent solutions.

Rather than being hosted on live web servers and fetched over HTTPS, these
applications are packaged into Web Bundles, signed by their developer, and
distributed to end-users through one or more of the potential methods
described in the explainer.

Blink component

UI>Browser>WebAppInstalls>Isolated (component request filed
)

Motivation

Content Security Policy (CSP) provides strong protection against cross-site
scripting (XSS) vulnerabilities. Transport Layer Security (TLS) and
Subresource Integrity (SRI) provide protection against resources being
tampered with in transit or when hosted on third-party servers. However,
the threat model for some particularly security sensitive applications
includes the main application server itself being compromised and serving
malicious content. This goes beyond the protections that current policies
can provide and requires exploring alternative ways that these applications
could be distributed and validated.

TAG review

Not yet filed.

Risks
Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals on this proposal but we’ve seen concerned
developers looking for solutions in this space. See the explainer for
details.

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?

As this concept only applies to installed web applications it won’t be
available in WebViews.


Debuggability

For the most part all the existing features to support debugability of PWAs
and Web Bundles will apply. However, we are considering adding additional
diagnostic messages to help developers understand when their application is
misbehaving due to the stricter policies.

Is this feature fully tested by web-platform-tests

?

No, web application installation is a //chrome concept which can’t be
exercised by web-platform-tests. Browser test infrastructure is in
isolated_app_test_utils.h

.

Flag name

Developers can add an origin to --isolated-app-origins to enable isolation
when installing a web app. Eventually this will support a real “developer
mode” more similar to how Extensions development works.

Requires code in //chrome?

Yes, while much of the implementation will live in Blink and //content the
web app installation infrastructure is implemented in //chrome.

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5146307550248960

This intent message was generated by Chrome Platform Status
.
Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome


-- 
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/CAEmk%3DMayyUjocrvyQKgu-bZy_4z5VJ0ijHCAijBTZY2xLwJpJQ%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate element's functionality

[Mason Freed]

On Mon, Apr 18, 2022 at 8:04 AM Joe Medley  wrote:

> Mason,
>
> In which version are you hoping to deprecate and in which are you hoping
> to remove?
>

That's a good question. Given that our expectation is for this to be not
very impactful, I was planning to do *both* starting in M102. My plan is to
disable the functionality very slowly via Finch, and monitor carefully for
reported bugs. Given that this will be in the long tail of sites, I had
planned to do that very slowly over the next few months, meaning milestones
between 102 and ~103/4 or so. Does that make sense? And if so, does it
answer your question concretely enough?

Thanks,
Mason




>
>
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Apr 13, 2022 at 9:48 AM Mason Freed  wrote:
>
>> Contact emailsmas...@chromium.org
>>
>> Explainerhttps://github.com/whatwg/html/pull/7816
>> https://github.com/whatwg/html/issues/6003
>>
>> Specificationhttps://github.com/whatwg/html/pull/7816
>>
>> Summary
>>
>> The  element can be used to specify parameters such as a URL (via
>> params named "movie", "src", "code", "data", or "url") to a containing
>>  element. Given the removal of plugins from the web platform, and
>> the relative lack of use of this particular functionality, we would like to
>> deprecate and remove it.
>>
>>
>> Blink componentBlink
>> 
>>
>> Motivation
>>
>> Given that plugins are gone from the web platform (with their full
>> removal from the spec being tracked in
>> https://github.com/whatwg/html/issues/6003), it is not useful. In some
>> browsers it can be used to figure out the URL of an , even when
>> that  is not being used for a plugin, via params named "movie",
>> "src", "code", "data", or "url". But we decided to remove this behavior
>> from browsers instead of specifying it. This retains the HTMLParamElement
>> interface, as well as the parser behavior of .
>>
>>
>> Initial public proposal
>>
>> Search tags ,
>>  
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> Gecko: Shipped/Shipping (
>> https://github.com/whatwg/html/issues/387#issuecomment-1088331300) Issue
>> was initially raised by Mozilla, and Gecko already does not process param
>> at all.
>>
>> WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=239188) No
>> response on the bug yet.
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>> Ergonomics
>>
>> Since this is a deprecation, there is a Web Compat risk. I added use
>> counters for the situations that will be affected: -  that specifies
>> a URL, inside an  that doesn't: 0.04%,
>> https://chromestatus.com/metrics/feature/timeline/popularity/4010 - As
>> above, but URL successfully resolves to a (supported) PDF resource:
>> 0.2%,
>> https://chromestatus.com/metrics/feature/timeline/popularity/4110 - As
>> above, but URL successfully resolves to an (unsupported) non-PDF resource:
>> not measurable,
>> https://chromestatus.com/metrics/feature/timeline/popularity/4111 So the
>> vast majority (99.95%) of  URL usage appears to point to invalid
>> resources - likely mostly Flash. A very small percentage (0.05% of
>> -with-URL usage, 0.2% of web page loads) are likely to break
>> when we deprecate this functionality.
>>
>>
>> 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
>>
>> Deprecation.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1315717
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6283184588193792
>>
>> 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/CAM%3DNeDhXTo%3Dg3scg7KF8g%3Dn5a4rA%3D6UD5cAxTBn9HetnAO%2BJ-A%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" grou

Re: [blink-dev] Intent to Ship: File Handling

[Chris Harrelson]

On Mon, Apr 18, 2022 at 9:21 AM Evan Stade  wrote:

> On Fri, Apr 15, 2022 at 3:03 PM Chris Harrelson 
> wrote:
>
>>
>>
>> On Fri, Apr 15, 2022 at 1:47 PM Evan Stade  wrote:
>>
>>> Contact emails
>>>
>>> est...@chromium.org, dmu...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/file-handling/blob/master/explainer.md
>>>
>>> Specification
>>>
>>>
>>> https://wicg.github.io/manifest-incubations/index.html#file_handlers-member
>>>
>>> Design docs
>>>
>>> https://tinyurl.com/file-handling-design
>>>
>>> Summary
>>>
>>> File Handling provides a way for web applications to declare the ability
>>> to handle files with given MIME types and extensions. The web application
>>> will receive an event when the user intends to open a file with that web
>>> application.
>>>
>>>
>>> Blink component
>>>
>>> UI>Browser>WebAppInstalls>FileHandling
>>> 
>>>
>>> Search tags
>>>
>>> files , file handling
>>> , mime
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/371
>>>
>>
>> The review performed was an early one almost 2 years ago. I've reopened
>> this issue so that the TAG can provide a full review.
>>
>>
>>>
>>> TAG review status
>>>
>>> Issues addressed
>>>
>>> Link to origin trial feedback summary
>>>
>>>
>>> https://plx.corp.google.com/scripts2/script_61._146b85__2bae_bb88_001a114abbb8
>>>
>>> Risks
>>>
>>> Interoperability and CompatibilityFails to become an interoperable part
>>> of the web if other browsers don't implement it.
>>>
>>> Sites can detect whether the feature exists, but polyfill or other
>>> fallbacks are unlikely to be possible or required. As this API is just one
>>> way to open a file in an app, apps will be able to open files with
>>> alternate means (such as  or drag and drop) regardless
>>> of the presence of this API.
>>>
>>>
>>> Gecko: N/A (https://github.com/mozilla/standards-positions/issues/629)
>>>
>>> WebKit: N/A (
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-April/032185.html)
>>>
>>> Web developers: Positive (
>>> https://discourse.wicg.io/t/proposal-ability-to-register-file-handlers/3084/4)
>>> Already being prototyped by at least construct.net and excalidraw.com,
>>> based on https://crbug.com/1126091 and https://crbug.com/1131445. We
>>> also have a major partner that we can't publicly disclose.
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> This feature relies on File System Access and the new
>>> LaunchQueue/LaunchHandler objects which are also to be used for
>>> `launch_handler`. No known performance risks.
>>>
>>>
>>> Activation
>>>
>>> Documentation and outreach will be helpful to understanding this API:
>>> https://web.dev/file-handling/
>>>
>>>
>>> Security
>>>
>>> Please see the security model:
>>> https://docs.google.com/document/d/1pTTO5MTSlxuqxpWL3pFblKB8y8SR0jPao8uAjJSUTp4/edit
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> n/a (not a WebView feature)
>>>
>>
>> Please make sure this feature is explicitly disabled on WebView.
>>
>
> Certainly. Is there a standard way of doing that, or can we keep on
> relying on the feature flag?
>

Here  is
one example; it does require a bit of code on top of a Blink
RuntimeEnabledFeature.


>
>
>>
>>
>>>
>>>
>>> Debuggability
>>>
>>> File handlers are shown along with the rest of the manifest in the
>>> developer console in the "application" tab. Parsing errors are surfaced
>>> there.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> Flag name
>>>
>>> #file-handling-api
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/829689
>>>
>>> Launch bug
>>>
>>> https://crbug.com/1284364
>>>
>>> Non-OSS dependencies
>>>
>>> Does the feature depend on any code or APIs outside the Chromium open
>>> source repository and its open-source dependencies to function?
>>>
>>> n/a
>>>
>>> Sample links
>>>
>>> https://principled-ring-yarrow.glitch.me/
>>>
>>> Estimated milestones
>>>
>>> OriginTrial last
>>>
>>> 94
>>>
>>> OriginTrial first
>>>
>>> 92
>>>
>>> DevTrial
>>>
>>> 92
>>>
>>> Launch
>>>
>>> 102
>>>
>>>
>>> Anticipated spec changes
>>>
>>> n/a
>>>
>>
>> Here you said "not applicable" but I think you mean there are no open
>> spec issues that would result in future compat or interop issues? However, 
>> this
>> issue  is one such
>> example that is currently open.
>>
>
> Correct, there are no know

[blink-dev] PSA: some tweaks to the Intent process

[Chris Harrelson]

Hi blink-dev,

The Blink API owners have enacted the following changes to the process:

* *Clarification of the number of milestones allowed for an Origin Trial,
with provision for extensions*. Origin Trials may run for up to 6
milestones with today's rules, and may be extended for up to 3 milestones
at a time if substantial progress is made towards meeting the bar for an
Intent to Ship. (Extensions still only require one LGTM.)

** Gapless shipping for all Origin Trials*. When a feature receives
approval to ship, a breaking period for any existing Origin Trial is no
longer required. (In other words, all features are automatically allowed to
ship in a "gapless" way.) This policy will be in place for 12 months, after
which the API owners will re-evaluate whether it introduces any new risks
in practice.

See here

for
more details on the changes to Origin Trials.

* *New Interop question*. There is a new question during the Intent to Ship
phase meant to assess risk of interop or compat due to unresolved
specification issues. The text is:

*Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).*

-- 
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/CAOMQ%2Bw8bORy9_hNLxmOkHhBBZ1%2BqX0jSWt5OCLaxhEQO2HM-8g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: File Handling

[Evan Stade]

On Fri, Apr 15, 2022 at 3:03 PM Chris Harrelson 
wrote:

>
>
> On Fri, Apr 15, 2022 at 1:47 PM Evan Stade  wrote:
>
>> Contact emails
>>
>> est...@chromium.org, dmu...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/file-handling/blob/master/explainer.md
>>
>> Specification
>>
>>
>> https://wicg.github.io/manifest-incubations/index.html#file_handlers-member
>>
>> Design docs
>>
>> https://tinyurl.com/file-handling-design
>>
>> Summary
>>
>> File Handling provides a way for web applications to declare the ability
>> to handle files with given MIME types and extensions. The web application
>> will receive an event when the user intends to open a file with that web
>> application.
>>
>>
>> Blink component
>>
>> UI>Browser>WebAppInstalls>FileHandling
>> 
>>
>> Search tags
>>
>> files , file handling
>> , mime
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/371
>>
>
> The review performed was an early one almost 2 years ago. I've reopened
> this issue so that the TAG can provide a full review.
>
>
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Link to origin trial feedback summary
>>
>>
>> https://plx.corp.google.com/scripts2/script_61._146b85__2bae_bb88_001a114abbb8
>>
>> Risks
>>
>> Interoperability and CompatibilityFails to become an interoperable part
>> of the web if other browsers don't implement it.
>>
>> Sites can detect whether the feature exists, but polyfill or other
>> fallbacks are unlikely to be possible or required. As this API is just one
>> way to open a file in an app, apps will be able to open files with
>> alternate means (such as  or drag and drop) regardless
>> of the presence of this API.
>>
>>
>> Gecko: N/A (https://github.com/mozilla/standards-positions/issues/629)
>>
>> WebKit: N/A (
>> https://lists.webkit.org/pipermail/webkit-dev/2022-April/032185.html)
>>
>> Web developers: Positive (
>> https://discourse.wicg.io/t/proposal-ability-to-register-file-handlers/3084/4)
>> Already being prototyped by at least construct.net and excalidraw.com,
>> based on https://crbug.com/1126091 and https://crbug.com/1131445. We
>> also have a major partner that we can't publicly disclose.
>>
>> Other signals:
>>
>> Ergonomics
>>
>> This feature relies on File System Access and the new
>> LaunchQueue/LaunchHandler objects which are also to be used for
>> `launch_handler`. No known performance risks.
>>
>>
>> Activation
>>
>> Documentation and outreach will be helpful to understanding this API:
>> https://web.dev/file-handling/
>>
>>
>> Security
>>
>> Please see the security model:
>> https://docs.google.com/document/d/1pTTO5MTSlxuqxpWL3pFblKB8y8SR0jPao8uAjJSUTp4/edit
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> n/a (not a WebView feature)
>>
>
> Please make sure this feature is explicitly disabled on WebView.
>

Certainly. Is there a standard way of doing that, or can we keep on relying
on the feature flag?


>
>
>>
>>
>> Debuggability
>>
>> File handlers are shown along with the rest of the manifest in the
>> developer console in the "application" tab. Parsing errors are surfaced
>> there.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> Flag name
>>
>> #file-handling-api
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://crbug.com/829689
>>
>> Launch bug
>>
>> https://crbug.com/1284364
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>>
>> n/a
>>
>> Sample links
>>
>> https://principled-ring-yarrow.glitch.me/
>>
>> Estimated milestones
>>
>> OriginTrial last
>>
>> 94
>>
>> OriginTrial first
>>
>> 92
>>
>> DevTrial
>>
>> 92
>>
>> Launch
>>
>> 102
>>
>>
>> Anticipated spec changes
>>
>> n/a
>>
>
> Here you said "not applicable" but I think you mean there are no open spec
> issues that would result in future compat or interop issues? However, this
> issue  is one such
> example that is currently open.
>

Correct, there are no known/anticipated changes to the proposed spec.

I don't think the linked issue would affect the API/spec itself. This seems
like more of a marketing issue. That is, the only part of the actual API
that might be relevant to the outcome of this issue is the manifest entry
named "file_handlers" and I think that should retain its current name.


>
>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.

[blink-dev] Intent to experiment: Deprecate and remove merchant identity in "canmakepayment"

['Rouslan Solomakhin' via blink-dev]

Contact emailsrous...@chromium.org

Specificationhttps://w3c.github.io/payment-handler/

Summary

This is an early heads up that we intend to remove the merchant origin and
arbitrary data from the "canmakepayment" service worker event of the
Payment Handler API. These are the event fields to be removed:


   - topOrigin
   - paymentReuqestOrigin
   - methodData
   - modifiers

The removal will be happening through the use of an origin trial at first,
then a reverse origin trial, and finally removal.
Blink componentBlink>Payments


MotivationThe “canmakepayment” service worker event lets the merchant know
whether the user has a card on file in an installed service-worker based
payment app. It silently passes the merchants’ origin and arbitrary data to
the service worker from the payment app origin. This cross-origin
communication happens on new PaymentRequest() construction in JavaScript,
does not require a user gesture, and does not show any user interface.

Alternatively, we have considered and dismissed the option to remove the “
canmakepayment” event entirely and behave as if it always returns "true",
because some payment app partners have indicated to us that's what they
always do. However, the data that we have collected shows that the “
canmakepayment” event returns "false" 1% to 6% of the time, depending on
the platform.

TAG review statusNot applicable

Risks
Interoperability and Compatibility

Only Chrome has implemented the Payment Handler API.

Chrome is reaching out to the known partners that may be depending on these
fields.

WebView application risks

The Payment Handler API requires the use of the PaymentRequest API. Neither
API is available in WebView.


Is this feature fully tested by web-platform-tests

?Yes


Flag namePaymentHandlerMerchantIdentity

Requires code in //chrome?True

Estimated milestones

Origin trial: 108

Reverse origin trial: 111

Removal: 114

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

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/CAMMzaWFz1UFWxgOs%2BECSdF2Bt8JpsBkGtv2wMnq2pemGMmD8Fw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[John Doe]

1. In Chrome 98, there were no preflight requests when accessing from 
public HTTPS to private HTTP, will the same be true in the final version?
2. In the case when I have a private HTTPS server that I want everyone to 
have access to (also via public HTTP), what options do I have ?

On Wednesday, April 6, 2022 at 8:23:58 PM UTC+3 Titouan Rigoudy wrote:

> Hi all,
>
> Thanks for the timely question, I was about to send an update here.
>
> We have fixed nearly all of the blockers identified in the above doc. The 
> only outstanding issue is the aforementioned crash, which required a bit 
> more design work than the rest. That work has been completed and CLs to fix 
> the problem are now in review; they should land shortly and make it in 
> Chrome 102.
>
> We would like to ship again in Chrome 102 in warning-only mode, just as we 
> last tried in Chrome 98. Preflights will be sent but their results will not 
> be enforced. Failed preflights will show warnings in DevTools, but requests 
> will otherwise continue unimpeded.
>
> Things will stay that way for at least 3 milestones. We will gather 
> compatibility data by monitoring failed preflights, then circle back here 
> to garner approvals to turn on enforcement. That launch will be accompanied 
> by a deprecation trial for web developers to sign up for a time extension 
> if they failed to notice the warnings in time.
>
> Cheers,
> Titouan
>
> On Wed, Apr 6, 2022 at 3:29 AM Logan Wei  wrote:
>
>> Hello,  is there now an updated timeline to roll out this change?  Will 
>> the trial restart in Chrome 102 or a later version?  
>>
>> On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:
>>
>>> Hi all,
>>>
>>> Here's the promised doc: 
>>> https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
>>>  
>>> (public, comment access for committers only)
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor  
>>> wrote:
>>>
 Thanks for the update Titouan. Looking forward to reading your doc.

 On 2/17/22 9:25 AM, Titouan Rigoudy wrote:

 Hi all, 

 Just to let you know that due to a couple issues, chief among which a 
 renderer crash (crbug.com/1279376), we are rolling this feature back 
 from Chrome 98.

 A few issues have been identified and will block our next attempt at 
 shipping this. In the meantime, we gathered some useful information about 
 impact and notified developers of the upcoming change. I'll write a doc 
 summarizing the timeline and lessons learned, then share as appropriate 
 here.

 Cheers,
 Titouan

 On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson  
 wrote:

> LGTM3 for step 1.
>
> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor  
> wrote:
>
>> LGTM2 for step 1.
>>
>> On 12/6/21 5:31 AM, Titouan Rigoudy wrote:
>>
>> *assuming I get 2 more LGTMs, that is.
>>
>> On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy  
>> wrote:
>>
>>> Thanks! I'll come back for further discussion with UKM data in hand. 
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Mon, Dec 6, 2021 at 10:58 AM Yoav Weiss  
>>> wrote:
>>>
 I agree UKM analysis should not block step 1, as it holds little 
 risk. (There's still some risks that servers will choke in the face of 
 preflights, but that seems minor compared to the enforcement risk) 

 Therefore,* LGTM1 for step 1* (preflights with no enforcement), 
 but not further (yet). Please come back to this thread with any data 
 you 
 may have as a result of adding UKMs.

 On Fri, Dec 3, 2021 at 6:44 PM 'Titouan Rigoudy' via blink-dev <
 blin...@chromium.org> wrote:

> Yoav, do you think UKM analysis should block sending preflights 
> without enforcing their success? I believe sending these will allow 
> us to 
> get more precise information on the affected websites through the 
> usecounter recorded in crrev.com/c/3310846. I can then analyze 
> UKM data and use the results to inform the decision whether and when 
> to 
> switch enforcement on? 
>
> Cheers,
> Titouan
>
> On Thu, Dec 2, 2021 at 5:19 PM Titouan Rigoudy  
> wrote:
>
>> I agree! 
>>
>> Cheers,
>> Titouan
>>
>> On Thu, Dec 2, 2021 at 5:17 PM Mike West  
>> wrote:
>>
>>> _I_ don't think we should do that, but I'd defer to Titouan's 
>>> preference. :) 
>>>
>>> -mike
>>>
>>>
>>> On Thu, Dec 2, 2021 at 5:14 PM Mike Taylor  
>>> wrote:
>>>
 Thanks - I also don't think there's a lot of value in this 
 particular header being the odd-one-out, just wanted to confirm 
 we'

[blink-dev] Intent to Prototype and Ship: Permissions Policy for Web Bluetooth API

['Gabriel Brito' via blink-dev]

Hi,

Hope you are doing well. We would like to request approval for this feature. 
Thank you in advance!


Contact emails
gabrielbr...@microsoft.com

Explainer
https://webbluetoothcg.github.io/web-bluetooth/#permissions-policy

Specification
https://webbluetoothcg.github.io/web-bluetooth/#permissions-policy

Summary

Integrates the Web Bluetooth API with Permissions Policy, which should be 
identified by the "bluetooth" token. The Web Bluetooth API allows webpages to 
communicate with devices over Bluetooth. However, this API is not allowed to be 
used from cross-origin iframes. This integration enables this scenario while 
providing protection against unwanted access to Bluetooth capabilities, which 
requires the top-level document to explicitly allow a cross-origin iframe to 
use the API's methods.


Blink component
Blink>Bluetooth

Risks


Interoperability and Compatibility

Low interoperability risks, since it is an integration of the Web Bluetooth API 
with Permissions Policy, which is already widely adopted. Also not explicitly 
allowing an iframe to use bluetooth with allow="bluetooth" won't affect the 
current behavior.


Gecko: No signal

WebKit: No signal

Web developers: Positive 
(https://bugs.chromium.org/p/chromium/issues/detail?id=518042)

Other signals:

Ergonomics

No anticipated ergonomic risks.



Activation

If developers would like to provide access to Web Bluetooth to cross-origin 
trusted iframes, they just need to add allow="bluetooth" to it.



Security

This integration makes the Web Bluetooth API more secure while keeping the 
current behavior and adding more capabilities to it.



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. Web Bluetooth is not available in WebView.


Debuggability

N/A (No DevTools support needed)


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

Flag name
No flag.

Requires code in //chrome?
False

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

Estimated milestones

No milestones specified


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop 
issues. Please list open issues (e.g. links to known github issues in the 
project for the feature specification) whose resolution may introduce web 
compat/interop risk (e.g., changing to naming or structure of the API in a 
non-backward-compatible way).


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

-- 
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/DM5PR21MB07484A5393FB162C3CE599D5D5F39%40DM5PR21MB0748.namprd21.prod.outlook.com.

Re: [blink-dev] Intent to Ship: Navigation API

[Mike Taylor]

LGTM1 - I'm excited about this API, and hopeful we can smooth over the 
subtle interop issues that you've documented. But I see this as a huge 
ergonomics win over the status quo, and am encouraged by the careful 
work y'all have done.


On 4/18/22 11:39 AM, Domenic Denicola wrote:



On Mon, Apr 18, 2022 at 10:49 AM Mike Taylor  
wrote:


On 4/12/22 12:08 PM, Domenic Denicola wrote:



Contact emails

dome...@chromium.org, jap...@chromium.org


Explainer

https://github.com/WICG/navigation-api/blob/main/README.md



(Aside: This explainer is a master-class in writing explainers.
Incredibly well done - I really appreciate the effort that went
into this).



Specification

https://wicg.github.io/navigation-api/



Summary

The window.navigation API provides the ability to intercept and
initiate navigations, as well as introspect an application's
history entries. This provides a more useful alternative to
window.history and window.location, specifically aimed at the
needs of single-page web applications.


(Note: this API was formerly known as the app history API.)


Blink component

Blink>History




TAG review

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


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



TAG review status

Issues addressed


Link to origin trial feedback summary


https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing




Risks


Interoperability

The biggest interoperability risk with this API is that it is
building on a rocky foundation. The existing session history spec
does not match browsers very well, and browsers do not match each
other. Since this new API layers on top of the existing model,
this could cause issues.


We have attempted to address this via a solid and well-tested
specification for the new API, as well as ongoing efforts in
whatwg/html PR #6315
and elsewhere on the
HTML Standard issue tracker

to
reform the foundational parts of the specification. For example,
although the navigation API's new events, such as
currententrychange, are fired at well-specified times, there is
an existing interop problem
regarding the timing
of popstate vs. hashchange events, which makes it difficult to
write tests for the ordering of currententrychange vs.
hashchange/popstate. Working on such existing interop issues and
specification problems, and then expanding the navigation API
test suite to cover any such interactions, is our team's top
priority after this launch. See also this tracking issue
.


I do have slight concerns

over the popstate/hashchange event change - I fear that might
result in more back button traps for Chromium users (that sadly
Gecko users experience today). But I could be wrong - do you have
any plans to measure and monitor abuse? Or do we have existing
metrics?


To make sure we are on the same page: at this point we are discussing 
a future Intent to Ship about a separate behavior change, and we are 
not discussing the Navigation API.


Correct - and to be extra clear, any potential future I2S is not 
influencing this I2S in my mind.


Our plan for that future Intent to Ship does indeed involve careful 
monitoring. However I don't think it has any chance of increasing 
back-trapping. Deterministically firing the events in the order (sync 
popstate, async hashchange) like Gecko does, instead of Chrome's 
version where sometimes it's (async popstate, async hashchange) and 
sometimes it's (async hashchange, async popstate) depending on network 
conditions and page size, should not increase back-trapping.

OK, I'm very happy to be wrong here. :)




Regarding whether this new API will be implemented in other
browsers, we have been encouraged by the consistent and positive
collaboration with Gecko engineers, which has led to several API
changes and a good amount of review. (We have no signal from WebKit.)


Compatibility

This has 

Re: [blink-dev] Intent to Ship: Navigation API

[Domenic Denicola]

On Mon, Apr 18, 2022 at 10:49 AM Mike Taylor  wrote:

> On 4/12/22 12:08 PM, Domenic Denicola wrote:
>
> Contact emails
>
> dome...@chromium.org, jap...@chromium.org
>
> Explainer
>
> https://github.com/WICG/navigation-api/blob/main/README.md
>
> (Aside: This explainer is a master-class in writing explainers. Incredibly
> well done - I really appreciate the effort that went into this).
>
>
> Specification
>
> https://wicg.github.io/navigation-api/
>
> Summary
>
> The window.navigation API provides the ability to intercept and initiate
> navigations, as well as introspect an application's history entries. This
> provides a more useful alternative to window.history and window.location,
> specifically aimed at the needs of single-page web applications.
>
> (Note: this API was formerly known as the app history API.)
>
> Blink component
>
> Blink>History
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/605
>
> https://github.com/w3ctag/design-reviews/issues/717
>
> TAG review status
>
> Issues addressed
>
> Link to origin trial feedback summary
>
>
> https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing
>
> Risks
> Interoperability
>
> The biggest interoperability risk with this API is that it is building on
> a rocky foundation. The existing session history spec does not match
> browsers very well, and browsers do not match each other. Since this new
> API layers on top of the existing model, this could cause issues.
>
> We have attempted to address this via a solid and well-tested
> specification for the new API, as well as ongoing efforts in whatwg/html
> PR #6315  and elsewhere on the
> HTML Standard issue tracker
> 
> to reform the foundational parts of the specification. For example,
> although the navigation API's new events, such as currententrychange, are
> fired at well-specified times, there is an existing interop problem
>  regarding the timing of
> popstate vs. hashchange events, which makes it difficult to write tests for
> the ordering of currententrychange vs. hashchange/popstate. Working on such
> existing interop issues and specification problems, and then expanding the
> navigation API test suite to cover any such interactions, is our team's top
> priority after this launch. See also this tracking issue
> .
>
> I do have slight concerns
>  over
> the popstate/hashchange event change - I fear that might result in more
> back button traps for Chromium users (that sadly Gecko users experience
> today). But I could be wrong - do you have any plans to measure and monitor
> abuse? Or do we have existing metrics?
>

To make sure we are on the same page: at this point we are discussing a
future Intent to Ship about a separate behavior change, and we are not
discussing the Navigation API.

Our plan for that future Intent to Ship does indeed involve careful
monitoring. However I don't think it has any chance of increasing
back-trapping. Deterministically firing the events in the order (sync
popstate, async hashchange) like Gecko does, instead of Chrome's version
where sometimes it's (async popstate, async hashchange) and sometimes it's
(async hashchange, async popstate) depending on network conditions and page
size, should not increase back-trapping.


>
> Regarding whether this new API will be implemented in other browsers, we
> have been encouraged by the consistent and positive collaboration with
> Gecko engineers, which has led to several API changes and a good amount of
> review. (We have no signal from WebKit.)
>
> Compatibility
>
> This has been the team's main focus for the last few months, as we burned
> through the list of potentially-compat-impacting issues
> . In collaboration
> with Gecko this led to several improvements, such as the API rename (from
> app history), a change 
> in how replacement navigations are requested, and the addition
>  of an indicator for
> when a download is requested. We believe the remaining issues (3 at the
> time of writing) are manageable:
>
>
>-
>
>#72 : this will
>result in firing an event more often during extreme edge case scenarios
>involving replacement navigations, or in less-rare-but-still-rare scenarios
>involving the user clearing their history. Neither case should prove
>problematic.
>-
>
>#207 

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate element's functionality

['Joe Medley' via blink-dev]

Mason,

In which version are you hoping to deprecate and in which are you hoping to
remove?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Apr 13, 2022 at 9:48 AM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> Explainerhttps://github.com/whatwg/html/pull/7816
> https://github.com/whatwg/html/issues/6003
>
> Specificationhttps://github.com/whatwg/html/pull/7816
>
> Summary
>
> The  element can be used to specify parameters such as a URL (via
> params named "movie", "src", "code", "data", or "url") to a containing
>  element. Given the removal of plugins from the web platform, and
> the relative lack of use of this particular functionality, we would like to
> deprecate and remove it.
>
>
> Blink componentBlink
> 
>
> Motivation
>
> Given that plugins are gone from the web platform (with their full removal
> from the spec being tracked in https://github.com/whatwg/html/issues/6003),
> it is not useful. In some browsers it can be used to figure out the URL of
> an , even when that  is not being used for a plugin, via
> params named "movie", "src", "code", "data", or "url". But we decided to
> remove this behavior from browsers instead of specifying it. This retains
> the HTMLParamElement interface, as well as the parser behavior of .
>
>
> Initial public proposal
>
> Search tags ,
>  
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Shipped/Shipping (
> https://github.com/whatwg/html/issues/387#issuecomment-1088331300) Issue
> was initially raised by Mozilla, and Gecko already does not process param
> at all.
>
> WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=239188) No
> response on the bug yet.
>
> Web developers: No signals
>
> Other signals:
>
> Ergonomics
>
> Since this is a deprecation, there is a Web Compat risk. I added use
> counters for the situations that will be affected: -  that specifies
> a URL, inside an  that doesn't: 0.04%,
> https://chromestatus.com/metrics/feature/timeline/popularity/4010 - As
> above, but URL successfully resolves to a (supported) PDF resource:
> 0.2%,
> https://chromestatus.com/metrics/feature/timeline/popularity/4110 - As
> above, but URL successfully resolves to an (unsupported) non-PDF resource:
> not measurable,
> https://chromestatus.com/metrics/feature/timeline/popularity/4111 So the
> vast majority (99.95%) of  URL usage appears to point to invalid
> resources - likely mostly Flash. A very small percentage (0.05% of
> -with-URL usage, 0.2% of web page loads) are likely to break
> when we deprecate this functionality.
>
>
> 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
>
> Deprecation.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1315717
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6283184588193792
>
> 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/CAM%3DNeDhXTo%3Dg3scg7KF8g%3Dn5a4rA%3D6UD5cAxTBn9HetnAO%2BJ-A%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/CAJUhtG9k2Ngc1jyOrvvF%2BpMVcB%2BmvaD2MYn6MOu-sCa%3DXm0H2Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Navigation API

[Mike Taylor]

On 4/12/22 12:08 PM, Domenic Denicola wrote:



Contact emails

dome...@chromium.org, jap...@chromium.org


Explainer

https://github.com/WICG/navigation-api/blob/main/README.md 



(Aside: This explainer is a master-class in writing explainers. 
Incredibly well done - I really appreciate the effort that went into this).



Specification

https://wicg.github.io/navigation-api/ 




Summary

The window.navigation API provides the ability to intercept and 
initiate navigations, as well as introspect an application's history 
entries. This provides a more useful alternative to window.history and 
window.location, specifically aimed at the needs of single-page web 
applications.



(Note: this API was formerly known as the app history API.)


Blink component

Blink>History 




TAG review

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



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




TAG review status

Issues addressed


Link to origin trial feedback summary

https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing 




Risks


Interoperability

The biggest interoperability risk with this API is that it is building 
on a rocky foundation. The existing session history spec does not 
match browsers very well, and browsers do not match each other. Since 
this new API layers on top of the existing model, this could cause issues.



We have attempted to address this via a solid and well-tested 
specification for the new API, as well as ongoing efforts in 
whatwg/html PR #6315 and 
elsewhere on the HTML Standard issue tracker 
to 
reform the foundational parts of the specification. For example, 
although the navigation API's new events, such as currententrychange, 
are fired at well-specified times, there is an existing interop 
problem regarding the 
timing of popstate vs. hashchange events, which makes it difficult to 
write tests for the ordering of currententrychange vs. 
hashchange/popstate. Working on such existing interop issues and 
specification problems, and then expanding the navigation API test 
suite to cover any such interactions, is our team's top priority after 
this launch. See also this tracking issue 
.


I do have slight concerns 
 
over the popstate/hashchange event change - I fear that might result in 
more back button traps for Chromium users (that sadly Gecko users 
experience today). But I could be wrong - do you have any plans to 
measure and monitor abuse? Or do we have existing metrics?


Regarding whether this new API will be implemented in other browsers, 
we have been encouraged by the consistent and positive collaboration 
with Gecko engineers, which has led to several API changes and a good 
amount of review. (We have no signal from WebKit.)



Compatibility

This has been the team's main focus for the last few months, as we 
burned through the list of potentially-compat-impacting issues 
. In collaboration 
with Gecko this led to several improvements, such as the API rename 
(from app history), a change 
in how replacement 
navigations are requested, and the addition 
of an indicator for 
when a download is requested. We believe the remaining issues (3 at 
the time of writing) are manageable:



 *

#72 : this will
result in firing an event more often during extreme edge case
scenarios involving replacement navigations, or in
less-rare-but-still-rare scenarios involving the user clearing
their history. Neither case should prove problematic.

 *

#207 : the most
likely solution will either be leaving things as they are, or
changing the timing of an event in a way that will not disturb
"normal" usage of the API. Although such a timing change could be
risky if this API had wide deployment, we believe that changing
the timing within a milestone or three would not be problematic if
it ends up being desirable.

 *

#202