Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

LGTM1 This is a change of default behavior, but the previous behavior is likely very rare and it can be achieved using `text-wrap: nowrap`. Since the text-wrap part is important for adoption of this, can you check if text-wrap.tentative.html still needs to be tentative? The test has a comment abo

Re: [blink-dev] Intent-to-Ship: MediaRecorder keyframe configurability

WPT addition is covered under https://github.com/web-platform-tests/wpt/issues/39642 and I haven't been able to prioritize that yet. I don't know what other vendors do. You're welcome to file a bug in the mediarecorder - not sure I think the issue raised here is terribly important but I could suppo

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

We do some interesting reorganization of ruby content in the a11y tree. Can we create some DumpAccessibilityTreeTest tests for this and I'll take a look at the a11y tree and make sure it's sensible. On Fri, May 31, 2024 at 4:49 AM TAMURA, Kent wrote: > Contact emailstk...@chromium.org > > Explai

Re: [blink-dev] Intent to Extend Experiment: Tabbed web apps

Makes sense to me. IMO more than one LGTM (or even my LGTM) is not necessary because the feature is already shipping, and in that sense this extension is a technicality. LGTM On Fri, May 31, 2024 at 3:47 PM Brett Wilson wrote: > Hi Blink owners, > > We would like to apply to extend the Tabbed w

[blink-dev] Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

Contact emails...@chromium.org ExplainerNone Specificationhttps://wicg.github.io/private-network-access Summary We propose to block access to IP address 0.0.0.0 in advance of PNA completely rolling out. Chrome is deprecating direct access to private network endpoints from public websites as par

[blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

Chrome Status doesn't generate emails for the deprecation trails, only developer trials, so I've repurposed that here. This is a Finch managed rollout, not a developer opt-in, due to the extremely low usage that seems to be almost entirely malware. On Mon, Jun 3, 2024 at 12:03 PM David Adrian wro

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

On Mon, Jun 3, 2024 at 12:06 PM 'David Adrian' via blink-dev < blink-dev@chromium.org> wrote: > Chrome Status doesn't generate emails for the deprecation trails, only > developer trials, so I've repurposed that here. This is a Finch managed > rollout, not a developer opt-in, due to the extremely l

Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport

Hmm, after I cleared out the wrong data, something filled it in again. I will try to track down that ChromeStatus bug today. Thanks, jason! On Sunday, June 2, 2024 at 4:59:33 PM UTC-7 Tsuyoshi Horo wrote: > Hi. > > On Sat, Jun 1, 2024 at 3:04 AM Jason Robbins wrote: > >> Tsuyoshi, >> >> Previ

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

> Can you please elaborate on the analysis: how low is the usage and how did you check that the use is malware? The Blink.UseCounter.Feature for PrivateNetworkAccessNullIpAddress shows below 0.001% on all platfo

Re: [blink-dev] Intent to Ship: Support Video Chapter in MediaMetadata

Hi Team, Thanks all for the LGTMs! To clarify, how many LGTMs are typically required before we can enable this feature to stable? Best, Jiaming On Fri, May 31, 2024 at 6:31 AM Mike Taylor wrote: > LGTM3 > On 5/31/24 4:08 AM, Yoav Weiss (@Shopify) wrote: > > LGTM2 > > On Fri, May 31, 2024 at 5:

[blink-dev] Intent to Ship: WebAuthn hints

Contact emails...@chromium.org Specificationhttps://w3c.github.io/webauthn/#enum-hints Summary The new `hints` parameter[1] in WebAuthn requests allows sites to provide guidance to browsers to guide their UI. The canonical use case are enterprises which know that their internal sites use only se

Re: [blink-dev] Intent to Ship: Support Video Chapter in MediaMetadata

Hi Jiaming, 3 LGTMs are needed. So you're good to go! Happy shipping. On Mon, Jun 3, 2024 at 1:56 PM 'Jiaming Cheng' via blink-dev < blink-dev@chromium.org> wrote: > Hi Team, > > Thanks all for the LGTMs! > To clarify, how many LGTMs are typically required before we can enable > this feature to

Re: [blink-dev] Intent to Ship: Support Video Chapter in MediaMetadata

Great! Thanks Chris! On Mon, Jun 3, 2024 at 2:00 PM Chris Harrelson wrote: > Hi Jiaming, > > 3 LGTMs are needed. So you're good to go! Happy shipping. > > On Mon, Jun 3, 2024 at 1:56 PM 'Jiaming Cheng' via blink-dev < > blink-dev@chromium.org> wrote: > >> Hi Team, >> >> Thanks all for the LGTMs!

[blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

> *Gecko*: Closed Without a Position ( https://github.com/mozilla/standards-positions/issues/143) It looks like it's closed with position: "worth prototyping", though? Or is there another issue that is closed without position? On Monday, June 3, 2024 at 6:04:03 PM UTC+2 dad...@google.com wrote

Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport

OK, I think that I found the problem and fixed it in ChromeStatus database. I reran the cron job that previously overwrote my simpler fix and it did not overwrite my more-complete fix. So, you should now see the "Request Trial Creation" button on the V3 OT stage, and it should still be there

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

On 6/4/24 6:26 AM, 'Kagami Rosylight' via blink-dev wrote: > /Gecko/: Closed Without a Position (https://github.com/mozilla/standards-positions/issues/143) It looks like it's closed with position: "worth prototyping", though? Or is there another issue that is closed without position? I can

Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport

Thanks! I just submitted the creation request. On Tue, Jun 4, 2024 at 7:34 AM Jason Robbins wrote: > OK, I think that I found the problem and fixed it in ChromeStatus > database. I reran the cron job that previously overwrote my simpler fix > and it did not overwrite my more-complete fix. So,

Re: [blink-dev] Re: Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

The text in the default Intent email is derived from the position issue's labels, and https://github.com/mozilla/standards-positions/issues/143 was closed before the Mozilla folks had created the labels we're looking for. We don't have great help text in Chrome Status to help feature owners figure

[blink-dev] Intent to Prototype: CSS Masonry

Contact emails etha...@microsoft.com, alma...@microsoft.com Explainer https://developer.chrome.com/blog/masonry A formal explainer is in the works, waiting for further discussion over CSSWG issues. Specification https://tabatkins.gi

Re: [blink-dev] Intent to Ship: Protected Audience: Allow trusted bidding signals to trigger interest group updates

On 5/31/24 11:40 PM, Paul Jensen wrote: Contact emails pauljen...@chromium.org Explainer https://github.com/WICG/turtledove/pull/1095 Specification https://github.com/WICG/turtledove/pull/1124

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

The test "text-wrap.tentative.html" is tentative because of text-wrap:balance and text-wrap:pretty. I'll do: - File a spec issue for them, and - Make a non-tetative test for text-wrap:nowrap. On Mon, Jun 3, 2024 at 5:57 PM Philip Jägenstedt wrote: > LGTM1 > > This is a change of default behavi

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

Sure. I'll make a DumpAccessibilityTreeTest with a line-broken . On Mon, Jun 3, 2024 at 11:00 PM Aaron Leventhal wrote: > We do some interesting reorganization of ruby content in the a11y tree. > Can we create some DumpAccessibilityTreeTest tests for this and I'll take > a look at the a11y tree

[blink-dev] Re: Intent to Prototype: Timing information for ServiceWorker Static routing API

Sorry. Forgot to CC blink-dev@, Let me resend the reply. Thanks so much for the input. > Please make sure that this new timing info abide by the Web Platform Security Guildeline: > https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/web-platform-security-guidelines.md#timer-resolu

Re: [blink-dev] Intent to Ship: WebAuthn hints

Hi Adam, Could you please request reviews (or N/A, if you have internal approvals) for Privacy, Security, and Enterprise bits in your chromestatus entry? thx, Mike On 6/4/24 5:59 AM, Adam Langley wrote: Contact emails a...@chromium.org Specification https://w3c.github.

Re: [blink-dev] Intent to Ship: WebAuthn hints

(oops, accidentally removed agl@ from To, fixing) On 6/4/24 11:35 AM, Mike Taylor wrote: Hi Adam, Could you please request reviews (or N/A, if you have internal approvals) for Privacy, Security, and Enterprise bits in your chromestatus entry? thx, Mike On 6/4/24 5:59 AM, Adam Langley wrot

Re: [blink-dev] Intent to Extend Deprecation Trial: Restrict "private network requests" for subresources from public websites to secure contexts.

Hi Emily, A few questions inline: On 6/1/24 5:05 AM, Emily Stark wrote: Contact emails est...@google.com, jdebla...@google.com, dadr...@google.com, l...@chromium.org, tito...@chromium.org, cl...@chromium.org, mk...@chromium.org, v...@chromium.org Explainer https://githu

Re: [blink-dev] Re: Intent to Prototype: Timing information for ServiceWorker Static routing API

2024年6月4日(火) 11:22 Keita Suzuki : > Sorry. Forgot to CC blink-dev@, Let me resend the reply. > > Thanks so much for the input. > > > Please make sure that this new timing info abide by the Web Platform > Security Guildeline: > > > https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

LGTM2 /Daniel On 2024-06-04 04:16, TAMURA, Kent wrote: The test "text-wrap.tentative.html" is tentative because of text-wrap:balance and text-wrap:pretty.  I'll do: - File a spec issue for them, and - Make a non-tetative test for text-wrap:nowrap. On Mon, Jun 3, 2024 at 5:57 PM Philip Jägens

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

LGTM3. It might be worth manually testing popular Japanese sites that use ruby to make sure this doesn't cause issues. But, I think it would be hard for sites to depend on specific line breaking behavior in a way that could cause breakage. On Tue, Jun 4, 2024 at 3:53 PM Daniel Bratell wrote: >