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

[Ayu Ishii]

Hi everyone, 

Updating the thread to inform that we have decided to extend the target 
milestone until we've properly informed our partners. Will update the 
thread again when we have a new target.

Thanks,
Ayu
On Tuesday, August 9, 2022 at 7:57:19 AM UTC-7 jmedley via Chromestatus 
wrote:

> My notes say this is shipping in 106. Regardless, please enter the 
> shipping milestone in the correct fields. (Click Edit all fields, the 
> scroll to the bottom.) Thanks, 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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/13fd6dd9-aceb-4fd8-af25-4603d523c478n%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Persistent Quota

[Ayu Ishii]

Hi everyone, just updating the thread to inform that this removal milestone 
has been changed to M106.

On Monday, July 18, 2022 at 2:13:53 PM UTC-7 Ayu Ishii wrote:

> Hi everyone,
>
> Thank you for the approvals! I apologize for the delay here.
>
> We've confirmed that our impacted partner is now migrated off and we are 
> ready to proceed.
> We are targeting deprecation for M105.
>
> Thanks,
> Ayu
>
> On Friday, January 14, 2022 at 3:23:00 PM UTC-8 Chris Fredrickson wrote:
>
>> Hi,
>>
>> Apologies for the delayed responses.
>>
>> Colm: there's no DevTools logging (e.g.) for eviction events, but you can 
>> observe storage eviction events on chrome://tracing, under the 
>> "browsing_data" category.
>>
>> Joe: we're waiting for an impacted partner before we ship this 
>> deprecation.
>>
>> Chris
>>
>> On Monday, January 10, 2022 at 9:59:43 AM UTC-5 Joe Medley wrote:
>>
>>> Hi,
>>>
>>> When are you planning to ship?
>>> 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 Fri, Jan 7, 2022 at 1:17 PM Colm O Flynn  
>>> wrote:
>>>
 Quick question in relation to this.

 Is there any debug logging one can enable if one thinks that the 
 browser is re-claiming files deleted from the temporary file system?
 i.e. Where the browser would log that is deleting file x because 
 storage limit has been hit?

 Thanks in advance



 On Thursday, August 5, 2021 at 11:18:30 PM UTC+1 Marijn Kruisselbrink 
 wrote:

> On Thu, Aug 5, 2021 at 2:41 PM Alex Russell  
> wrote:
>
>> Do we have stats on potential storage pressure evictions that would 
>> be changed as a result of this change (as that appears to be the only 
>> place 
>> behavior differs)? And is there any UI that we display (e.g. in 
>> cache/storage clearing) that will be affected?
>>
> Good questions. No, I don't think we have stats that would tell us 
> potential changes to storage pressure evictions as a result of this 
> change. 
> Data stored in the persistent file system would indeed go from never 
> being 
> evicted today to being evicted with all other data an origin stores. 
> Having 
> said that, in more than 99.9% of the cases where we evict data, that data 
> has been last accessed years ago.
>
> As far as affected UI, the current UI isn't very good in displaying 
> this legacy persistent storage. I don't expect any of the storage 
> management UI to change, if anything getting rid of persistent quota will 
> mean less chance for bugs where we might inadvertently not count or 
> include 
> persistent storage when displaying information about a site. The main 
> thing 
> that will change UI wise is that there will no longer be a "foo.com 
> wants to permanently store data on your device" permission prompt that 
> accompanied usage of persistent quota.
>
>
>> On Thursday, July 29, 2021 at 4:13:57 PM UTC-7 Chris Harrelson wrote:
>>
> LGTM2
>>>
>>> On Wed, Jul 28, 2021 at 9:48 AM Yoav Weiss  
>>> wrote:
>>>
>> Thanks for clarifying! This seems like a low risk indeed.

 *LGTM1* to deprecate and remove (while keeping track of related 
 issue, just in case)

 On Wed, Jul 28, 2021 at 6:41 PM Marijn Kruisselbrink <
 m...@chromium.org> wrote:

>>> To elaborate a bit more on the potential for breakage, I believe the 
> only way a website could be truly broken from this change is if it 
> somehow 
> relies on temporary and persistent quota being separate buckets. Not 
> sure 
> what kind of logic they would have to employ to actually be broken by 
> that 
> no longer being the case though. As such my expectation is that it is 
> extremely unlikely that any site will be broken by this. Certainly 
> none of 
> the sites in httparchive I looked at.
>
 On Mon, Jul 26, 2021 at 1:25 PM Marijn Kruisselbrink <
> m...@chromium.org> wrote:
>
 On Mon, Jul 26, 2021 at 2:26 AM Yoav Weiss  
>> wrote:
>>
>>> Since the 0.4% usage numbers are suspected to be a very loose 
>>> upper-bound, I wonder what's the best strategy here.
>>> Is there a way to use-count cases where storage quota would run 
>>> out as temporary but not as persistent? 
>>>
>> Good question. I think today we actually generally allow websites 
>> to store much more data in the temporary quota bucket than in the 
>> persistent quota bucket. The latter is capped at 10GB, while the 
>> former in 
>> our histograms is more than 10GB 97% of the time on desktop, and 
>> even on 
>> mobile is larger than that 

[blink-dev] Intent to Implement and Ship: Rich PWA installation dialogs - desktop

[Phillis Tang]

Contact emailsphil...@chromium.org

Explainerhttps://github.com/w3c/manifest-app-info/blob/main/explainer.md

Specificationhttps://www.w3.org/TR/manifest-app-info

This feature has been shipped on Mobile - see previous status entry
 and I2S

.
Enabling this on the desktop uses the same "description" and "screenshots"
fields.

We additionally implemented parsing for the screenshots' "platform
" member, but
that was included in the original spec and design.

Summary

Gives developers the ability to add more data (descriptions and
screenshots) to their PWA install dialog and gives users more insight into
the apps they are about to install. This implements PWA richer install UI
on desktop. See previous chromstatus entry for mobile -
https://chromestatus.com/feature/6422599217184768


Blink componentUI>Browser>WebAppInstalls>Desktop


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/30

TAG review statusIssues addressed

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Positive


*Other signals*:

WebView application risks

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



Debuggability



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

Is this feature fully tested by web-platform-tests

?No, there is an open issue for this:
https://github.com/w3c/manifest-app-info/issues/26


Flag namechrome://flags/#enable-desktop-pwas-detailed-install-dialog

Requires code in //chrome?Yes

Tracking bughttps://crbug.com/1326252

Launch bughttps://crbug.com/1326714

Estimated milestones

106


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).
https://github.com/w3c/manifest-app-info/issues/55

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

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/CABcACaihvDYf47Z%3Dxivbr_NOXgBMW6NbL01av%3D4_FHEA9UXiPw%40mail.gmail.com.

[blink-dev] Intent to Extend Experiment: Conditional Focus

['Elad Alon' via blink-dev]

Hi Blink owners,

We'd like to extend the Conditional Focus experiment. It is currently
running m102-m105, and we'd like to extend by 3 additional milestones,
making it m102-m108 (inclusive).

Contact emailselada...@chromium.org

Explainerhttps://github.com/WICG/conditional-focus/blob/main/README.md

Specificationhttps://wicg.github.io/conditional-focus

Design docs
https://docs.google.com/document/d/1LHJRt-ry9hwzFTbPxKrmD0VvtEFEU6lvqsD7k6wwGKM

Summary

Extend the getDisplayMedia() APIs to ensure that tab-capture and
window-capture return a new subclass of MediaStreamTrack called
FocusableMediaStreamTrack. This new subclass exposes the focus() method.
This new method allows Web-applications, when capture starts, to decide
whether the captured tab/window should be immediately focused, or whether
the capturing tab+window should remain the focused one.


Blink componentBlink


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/679

TAG review statusPending

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

Ergonomics

N/A


Activation

Not challenging - just feature-detect: // Pre-existing functionality: const
mediaStream = await navigator.mediaDevices.getDisplayMedia(); const [track]
= mediaStream.getVideoTracks(); // New functionality behind
feature-detection: if (!!track.focus) { track.focus(...); }


Security

See design-doc.

Reason this experiment is being extended

0. Some relevant background: Originally, this feature ended up ready and in
Origin Trial quite some time before our partners were ready to take
advantage and participate in the experiment. The OT was therefore *shifted* and
*restarted* multiple times, eventually landing on the range of m102-m105.
Our partners are now ready and have started rolling out code taking
advantage of this feature - so far internally within their organization,
and soon to the general public.
1. More time is required for our partners' deliberate rollout to reach more
users, allowing these partners to provide more accurate, battle-tested
feedback.
2. Mozilla and Apple have both engaged positively with the proposal (see
here ).
Mozilla has made a proposal

for a general change to getDisplayMedia(), and suggested that the API shape
of Conditional Focus should be altered to fit that new shape. The added
complexity of tying Conditional Focus to adjacent API changes prolongs the
time to finalize Conditional Focus. While this is ongoing, we should keep
supporting partners who have invested engineering time in this OT.

We are therefore requesting extension by 3 milestones, making the
experiment run for m102-m108 (inclusive).

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

Supported on all Desktop platforms, but not on any mobile platforms.


Is this feature fully tested by web-platform-tests

?No

Flag nameConditionalFocus

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

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1214483

Estimated milestones
OriginTrial desktop last 105 (but extension to 108 hereby requested)
OriginTrial desktop first 102

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/lbuqOGx07xY
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/I4RE2pbocTg


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

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

['Eric Melgaard' via blink-dev]

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

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

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

> I checked the WebView-specific UseCounter too and it's half that of the 
> Android one. So yeah, it seems extremely unlikely to me that anyone will 
> notice this - more like a bug-fix than a deprecation. LGTM3
>
> On Fri, Jun 3, 2022 at 3:23 AM Yoav Weiss  wrote:
>
>> LGTM2
>>
>> On Thu, Jun 2, 2022 at 8:20 PM Daniel Bratell  wrote:
>>
>>> Well below our customary threshold level, and unlikely to be used in our 
>>> blind spots (WebView, enterprise). I think it's safe to remove directly.
>>>
>>> LGTM1
>>>
>>> /Daniel
>>> On 2022-06-02 19:40, Mike Taylor wrote:
>>>
>>> *Contact emails* 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> * mike...@chromium.org, m...@chromium.org Summary We propose to remove 
>>> support for navigating to filesystem:// URLs in iframes. Blink component 
>>> Blink>Storage>FileSystem 
>>> 
>>>  
>>> Motivation Render-initiated navigations to filesystem:// URLs are blocked 
>>> in top-level frames, but are currently allowed in iframes. As part of the 
>>> storage partitioning efforts, we propose to remove support for navigation 
>>> to filesystem:// URLs in iframes. Preventing navigation in third-party 
>>> contexts would be sufficient for our privacy goals, but as usage is almost 
>>> non-existent, we believe removing support for navigation in iframes 
>>> altogether is the better approach. 
>>> (https://miketaylr.com/misc/filesystem-navigation.html 
>>>  may be useful to 
>>> grok what any of this means.) TAG review N/A. This intent refers to a 
>>> Chromium-only feature (which we’re trying to remove). Risks 
>>> Interoperability and Compatibility No other engine supports filesystem:// 
>>> URLs, so we do not expect interoperability issues. As for compatibility, 
>>> usage is very, very low. Currently just above 0.008% 
>>> . For 
>>> this reason we would like to just remove it, without any deprecation 
>>> period. Gecko: N/A (not supported) WebKit: N/A (not supported) Web 
>>> developers: No signals Other signals: WebView application risks Does this 
>>> intent deprecate or change behavior of existing APIs, such that it has 
>>> potentially high risk for Android WebView-based applications? No. 
>>> Debuggability We currently send an error message to the console if you try 
>>> to open a window to a filesystem:// URL - we will do something similar for 
>>> iframes. Is this feature fully tested by web-platform-tests 
>>> ?
>>>  
>>> No Flag name FileSystemUrlNavigation Requires code in //chrome? False 
>>> Estimated milestones M105 Link to entry on the Chrome Platform Status 
>>> https://chromestatus.com/feature/5816343679991808 
>>>  This intent message was 
>>> generated by Chrome Platform Status . *
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/84b7af7f-66fb-4874-0290-f0b22f51cb52%40chromium.org
>>>  
>>> 
>>> .
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b9ca44ab-0655-8e86-a714-aad7ea463b25%40gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> 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/CAL5BFfW5x6mzXJXAngGT1m82jEr3hTM_WPShKi4tnJLvGXgWKQ%40mail.gmail.com
>>  
>> 

[blink-dev] Intent to Ship: Prerender2 for Desktop

['Angel Raposo' via blink-dev]

Contact emails

toyos...@chromium.org, angelrapo...@google.com

Explainer

This I2S aims to expand our efforts on Prerender2 (currently shipped only
on Android) to Desktop.

The full prerendering revamped explainer can be found at

https://github.com/WICG/nav-speculation/blob/main/README.md

Specification

https://wicg.github.io/nav-speculation/prerendering.html

Design docs

https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs

Summary

Prerendering is “pre”-rendering, it’s about pre-loading and rendering a Web
page before the user actually navigates to it. The main goal of
prerendering is to make the next page navigation faster, or ideally nearly
instant.

Sites can inform the user agent about which pages the user may likely
visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
user is at page A and will likely navigate to page B next). Once the
prerender is triggered, the browser pre-fetches the main resource,
instantiates a hidden page, and processes the main resource to fetch and
process more subresources.

After shipping Prerender2 for Android (I2S speculation rules triggered
Prerender2

and I2S for Omnibox triggered Prerender2
),
we are now requesting approval to ship Prerender2 for Desktop. This release
will enable the same triggers (speculation rules and Omnibox) for Desktop.

With this feature, Chrome (Desktop) will start prerendering high-confidence
URL suggestions provided by the page using speculation rules or directly by
Omnibox. During the prerendering process, a page will process and construct
the full DOM tree, including the execution of scripts (this differs
from No-state
Prefetch
 which
only prefetches resources and doesn’t execute scripts).

Note that we are not shipping cross-origin prerendering, which allows a web
page to prerender another page on a different origin.


Blink component

Internals>Preload>Prerender


TAG review

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

TAG review status

All issues have been addressed.

Risks


Interoperability and Compatibility

Interoperability risk: this feature is focused on enabling Prerender on
Desktop, which is already launched and available for Android.

We believe that some browsers already have prerendering implementations
which are not specified and may differ from each other, or not always
exposed to the platform. Our vision is to produce a specification that can
help improve interoperability. There is a risk that other browsers do not
converge on a prerendering standard but we hope that we’ll be able to
address legitimate concerns if any are raised by interested parties.

Compatibility risk: this feature is focused on enabling Prerender on
Desktop, which is already launched and available for Android. There are
some use cases that will need to know whether a page is being prerendered
by the user agent or navigated by the user, e.g. ads and analytics are
likely examples of this which are supported by already launched features
such as `document.prerendering` which lets a page know that it’s being
prerendered.

Chrome Extensions have abilities to interact with web contents and have
widely used API surfaces. We’ve been keeping in mind compatibility with
Extensions’ compatibility, including giving enough capability for
Extensions to properly support Prerender2 [1].

A similar concern applies to (P)NaCl/PPAPI. However, these plugins are on a
deprecation path. In the meantime, given that NaCl permits the page to
perform powerful operations, we are taking the safe route by canceling
prerendering if it triggers  a request to load a NaCl module.

[1]
https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs/edit


Gecko: When we launched Prerender2 for Android, we had some informal
positive discussion with Gecko engineers on the HTML Standard issue tracker
 and in
the HTML triage call
;
formal positions request here:
https://github.com/mozilla/standards-positions/issues/613


WebKit: WebKit already ships URL-bar triggered prerendering, but not any
APIs for letting pages know about it, and it's unclear what strategy they
are using to prohibit disruptive behaviors for prerendered pages. When we
launched Prerender2 for Android, we reached out for a formal positions
request here in the hopes of moving toward interoperability:
https://lists.webkit.org/pipermail/webkit-dev/2022-February/032113.html

Web developers: When we launched Prerender2 for Android, we received
positive feedback from