[blink-dev] PSA: Fire beforeinput event before compositionupdate event during IME composition.

['Siye Liu' via blink-dev]

Hi blink-dev,

We've been landing a change 
to 
enable new event ordering for beforeinput and compositionupdate during IME 
composition.

The previous event ordering for IME composition was:

keydown -> compositionstart -> *beforeinput -> compositionupdate* -> input 
-> keyup -> keydown -> *beforeinput -> compositionupdate* -> textInput -> 
input -> compositionend -> keyup.

The new ordering is:

keydown -> compositionstart -> *compositionupdate -> beforeinput* -> input 
-> keyup -> keydown -> *compositionupdate -> beforeinput* -> textInput -> 
input -> compositionend -> keyup.

This change aligns our event ordering with the behavior of Firefox and 
Safari, which fire the beforeinput event after the compositionupdate event.

The new event ordering is controlled by a runtime enabled feature flag that 
is set to stable status (enabled by default).

-- 
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/bc3e3ab9-0740-4a4a-83f9-f95694f0127cn%40chromium.org.

[blink-dev] Intent to Ship: Intersection Observer Scroll Margin

[Traian Captan]

Contact emailstcap...@chromium.org

ExplainerNone

Specification
https://w3c.github.io/IntersectionObserver/#dom-intersectionobserver-scrollmargin

Summary

Intersection Observer scrollMargin allows developers to observe targets
inside nested scroll containers that are currently clipped away by the
scroll containers. This is achieved by expanding the container's clipping
rect by the scrollMargin when calculating the intersection.


Blink componentBlink


Search tagsIntersection Observer
,
scrollMargin 

TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


*Gecko*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)

*WebKit*: Positive (https://github.com/w3c/IntersectionObserver/issues/431)

*Web developers*: Positive (
https://github.com/w3c/IntersectionObserver/issues/431)

*Other signals*:

Ergonomics

N/A


Activation

N/A


Security

N/A


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?

None


Debuggability

N/A


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

Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsIntersectionObserverScrollMargin

Finch feature nameNone

Non-finch justification

This feature is behind an enabled-by-default flag that can be disabled if
needed.


Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1469500

Estimated milestones
Shipping on desktop 119
DevTrial on desktop 119
Shipping on Android 119
DevTrial on Android 119
Shipping on WebView 119

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).
None

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsWGzF5au6c5%2BfVrh1hOCq_Y0rY0VF_bsmO8VVysg3QTg%40mail.gmail.com

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/CAFxahvvtjzdbMtPZ7e6Qc3%2BX%2B%3DedCQXLJp5AxZhXtGJHPznfXA%40mail.gmail.com.

[blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

[Alex Turner]

Contact emailsale...@chromium.org

Specification

   -

   Null report fixes:
   https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
   -

   Debug mode eligibility changes:
   https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
   -

   Padding report payloads:
   https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
   https://github.com/WICG/attribution-reporting-api/pull/1030
   -

   Reducing delay:
   https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103


Summary

We're planning a few bundled changes to Private Aggregation:

   -

   Null report fixes: Currently reports with no contributions are
   inadvertently dropped. This change ensures that, when a context ID is
   specified, a null report is sent even if budget is denied. Separately, it
   fixes a bug causing budget to always be denied for null reports.
   -

   Debug mode eligibility changes: Currently, debug mode is always
   available. This change only allows debug mode for callers that are allowed
   access to third-party cookies, silently dropping the debug mode otherwise.
   Note that this will allow debug mode to automatically sunset when
   third-party cookies are deprecated.
   -

   Padding report payloads: To avoid the payload size being dependent on
   the number of contributions, we will pad it with 'null' contributions to a
   fixed length. **Note**: this change will also affect Attribution
   Reporting’s aggregatable reports.
   -

   Reducing delay: When a context ID is specified, we remove the randomized
   10-60 minute delay, which is superfluous as a report is always sent in this
   case. Instead, we just wait until the Shared Storage operation timeout.


Blink componentBlink>PrivateAggregation


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have not
requested a signal for these changes specifically.)

TAG review statusPending

Risks


Interoperability and Compatibility


   - Null report fixes: Increases the number of reports sent to reporting
   endpoints, reporting endpoints using plaintext debug payloads will need to
   handle the null report case.
   - Debug mode eligibility changes: Backwards incompatible for callers
   using enableDebugMode() without third-party cookie eligibility.
   - Padding report payloads: Compatible with existing aggregation service
   versions. Reporting endpoints will see larger payloads and null
   contributions added to the plaintext debug payloads (if used).
   - Reducing delay: Should not require any reporting endpoint changes,
   reports will simply arrive earlier.


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/805). We have not
requested a signal for these changes specifically. The Gecko position on
Shared Storage (one of the ways Private Aggregation is exposed) is negative.

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/189). We have not
requested a signal for these changes specifically

*Web developers*: Positive for reducing delay

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

None


Debuggability

No new debug capabilities beyond the existing internals page
(chrome://private-aggregation-internals) and temporary debug mode.


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

All but Webview


Is this feature fully tested by web-platform-tests

?WPTs will be added when features are enabled.

Flag name on chrome://flagsNone

Finch feature namePadding: PrivacySandboxAggregationServiceReportPadding
All other features: PrivateAggregationApiBundledEnhancements

Requires code in //chrome?Only for settings checks

Tracking bughttps://crbug.com/1481761

Launch bughttps://launch.corp.google.com/launch/4272421

Estimated milestones

We intend to ship in M119.

Anticipated spec changes
None

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

Links to previous Intent discussions

Previous I2S


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/CAA%2BBiF%3DMBk5ra9sn9i4ajaNSd9aMFKE_9DpxE8pziGY6YXB9Mg%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: NavigateEvent sourceElement

['Vladimir Levin' via blink-dev]

On Mon, Sep 25, 2023 at 3:41 PM Nate Chapin  wrote:

> Contact emailsjap...@chromium.org, dome...@chromium.org
>
> Explainer
> https://github.com/WICG/navigation-api/commit/85edaf1d4d42355b020807cd56f6a22784978c3d
>
> SpecificationNone
>
> Summary
>
> When a navigation is initiated by an Element (i.e., a link click or a form
> submission), the sourceElement property on the NavigateEvent will be the
> initiating element.
>
>
> Blink componentBlink>History
> 
>
> Motivation
>
> This was requested by web developers. It provides an easy way to
> disambiguate which of several possible elements initiated a navigation.
>
>
> Initial public proposalhttps://github.com/WICG/navigation-api/issues/225
>
> TAG review
>

FWIW, TAG review is here:
https://github.com/w3ctag/design-reviews/issues/867


>
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Strongly positive (
> https://github.com/WICG/navigation-api/issues/225)
>
> *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?
>
> None
>
>
> Debuggability
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1483000
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5134353390895104
>
> 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/CACf%3D2LK%3DHeSj%2B5eQt1O23-TiO6Mai%2Bhdv-E%3DzMguriouYi6gVw%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/CADsXd2OqwC5AOHTqZXR6txmcHerfSDkY-z8RvDEJ8Df%2BvDQyyQ%40mail.gmail.com.

[blink-dev] Intent to Prototype: NavigateEvent sourceElement

[Nate Chapin]

Contact emailsjap...@chromium.org, dome...@chromium.org

Explainer
https://github.com/WICG/navigation-api/commit/85edaf1d4d42355b020807cd56f6a22784978c3d

SpecificationNone

Summary

When a navigation is initiated by an Element (i.e., a link click or a form
submission), the sourceElement property on the NavigateEvent will be the
initiating element.


Blink componentBlink>History


Motivation

This was requested by web developers. It provides an easy way to
disambiguate which of several possible elements initiated a navigation.


Initial public proposalhttps://github.com/WICG/navigation-api/issues/225

TAG review

TAG review statusPending

Risks


Interoperability and Compatibility

None


*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Strongly positive (
https://github.com/WICG/navigation-api/issues/225)

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

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1483000

Estimated milestones

No milestones specified


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

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/CACf%3D2LK%3DHeSj%2B5eQt1O23-TiO6Mai%2Bhdv-E%3DzMguriouYi6gVw%40mail.gmail.com.

Re: [blink-dev] Intent to Implement: Serial API

[Reilly Grant]

Errors such as buffer overruns are non-fatal. After the ReadableStream
closes with an error the SerialPort's readable attribute is replaced by a
new ReadableStream.
Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome



On Thu, Sep 14, 2023 at 1:07 AM amir karimi 
wrote:

> Hi,
>
> I hope you are well.
>
> I have been trying o get WebSerial working in my React app. It works fine
> in ideal conditions. However, if the serial device spams the serial port
> with a lot of data very fast before serialport.connect() happens, I get
> "BufferOverrunError".
> I increased the buffer size from 255 to 4095 but still it fails. Is there
> any method to empty the buffer or recover from the error when this happens?
>
> Thanks,
>
> Amir
> On Tuesday, September 18, 2018 at 5:50:38 PM UTC+1 Reilly Grant wrote:
>
>> The UI treatment will mirror that of WebUSB. The lack of content settings
>> and page info listings for Web Bluetooth permissions is a bug and will be
>> fixed when persistent permissions are implemented, as they are for WebUSB.
>> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome
>> 
>>
>>
>> On Mon, Sep 17, 2018 at 5:56 PM Lucas Garron  wrote:
>>
>>> Do you have any specific plans for UI treatment and content settings yet?
>>>
>>> Bluetooth pairing has special case (tab icon only, no content setting or
>>> page info listing) that doesn't scale to many permissions, and I would
>>> personally like to see focus on the mental model of Page Info as the
>>> one-stop-shop for info and management of the current page's permissions.
>>>
>>> »Lucas
>>>
>>> On Mon, Sep 17, 2018 at 4:51 PM Reilly Grant 
>>> wrote:
>>>
 Contact emails

 rei...@chromium.org

 Explainer

 https://github.com/reillyeon/serial/blob/explainer/EXPLAINER.md

 Spec

 https://wicg.github.io/serial

 Summary

 The Serial API provides an interface for connecting to physical and
 virtual serial ports. It will share the same chooser-based permissions
 model as other hardware APIs such as Web Bluetooth and WebUSB. Development
 of the specification will proceed in parallel to implementation.

 Motivation

 Operating systems require applications to use different APIs depending
 on what interface a device exposes. The Serial API fills a gap left by Web
 Bluetooth and WebUSB where devices which implement a serial port interface
 are not covered by neither the former (because it does not support
 Bluetooth Classic) nor the latter (because a system driver has already
 claimed exclusive access to the device).

 Risks

 Interoperability and Compatibility

 The primary risk of this API is that it will not be implemented by
 other vendors. It shared a lot with the Web Bluetooth and WebUSB APIs which
 so far have only been implemented by Chrome. While there have been no
 public signals from Edge and Safari it is clear from the fact that the
 original specification was abandoned by Mozilla (and their reaction to
 similar specifications) that Firefox’s position is negative. Web
 developers, commenting on the proposal to incubate this specification in
 the WICG, have displayed overwhelmingly positive support because of the
 possibilities it opens up for supporting additional hardware devices.

 Edge: No signals

 Firefox: Negative signals

 Safari: No signals

 Web developers: Positive signals
 

 Ergonomics

 Developers using this API may also be building applications that use
 other hardware APIs such as Web Bluetooth and WebUSB. Each of these
 interfaces have differences that reflect the underlying transport however
 we should be sure that user-facing abstractions such as permissions are
 handled in a consistent way. Integration with the Permissions API could,
 for example, permit authors to request permission to access a device across
 multiple API surfaces, this solving the problem of a device which may be
 accessible via the Serial API on platforms which include a driver for it,
 with a fallback to WebUSB on platforms without.

 Activation

 Developers should be able to take advantage of this API immediately.
 Those using the chrome.serial API (only available to Chrome Apps) will find
 it relatively easy to port their applications.

 Debuggability

 This is a JavaScript interface supported by the existing DevTools
 debugger.

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

 This feature will be supported by all platforms except Android WebView.

 Is this feature fully tested by web

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

[Yoav Weiss]

LGTM1 to remove support, given that 0.009% of TLS connections divided by
~30 is roughly at our typical threshold. Also given the dominance of
subresource TLS connections, it's likely that breakage would hit one of
those subresources, making it less likely to cause functional damage
(compared to e.g. the navigation request TLS connection).

On Mon, Sep 25, 2023 at 6:03 PM David Adrian  wrote:

> There are approximately 30x TLS connections relative to pageloads, due to
> subresources. Once you have a TLS connection open for a main frame, I'm not
> sure how many page loads happen across it. Probably a lot, but it's still
> dominated by subresources.
>
> In practice, the 0.02% bound appears to have shaken out to sub 0.01%
> (0.009%), determined by looking at differences in the "OK" result for
> Net.SSL_Connection_Error.
>
> On Tue, Sep 19, 2023 at 8:59 PM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Sep 20, 2023 at 12:47 AM David Benjamin 
>> wrote:
>>
>>> On Tue, Sep 19, 2023 at 1:50 AM Yoav Weiss 
>>> wrote:
>>>
 On Tue, Sep 19, 2023 at 7:45 AM Yoav Weiss 
 wrote:

> On Tue, Sep 19, 2023 at 1:35 AM 'Jeffrey Yasskin' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> On Mon, Sep 18, 2023 at 4:11 PM David Adrian 
>> wrote:
>>
>>> > This should probably be an "Intent to Deprecate and Remove" rather
>>> than an "Intent to Ship".
>>>
>>> You're absolutely right that it should be, unfortunately that's not
>>> the subject Chrome Status generated. I'll file an issue.
>>>
>>
>> Oops, yes, you did everything right here. There's already
>> https://github.com/GoogleChrome/chromium-dashboard/issues/2749 about
>> changing this subject line, and now
>> https://github.com/GoogleChrome/chromium-dashboard/issues/3346 to
>> align the Chrome Status UI with the launching-features page.
>>
>> > The RFC's introduction at
>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a
>>> pretty good explainer for why we should remove SHA-1 signatures.
>>>
>>> Agreed. Noting in general, there is a large process mismatch between
>>> TLS launches and the Blink launch process, as discussed in
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CmlXjQeNWDI/m/r-AUe0OqAQAJ.
>>> That's why this Intent looks a little different.
>>>
>>
> I wouldn't categorize it as a large process mismatch. But that's an
> orthogonal discussion.
>
>
>>
>>> As for the launch itself, I'll note it's been at 10% on Finch for a
>>> couple weeks and everything looks gray, so we should be safe to ramp up 
>>> to
>>> 100%. The only thing of note was a correlation with an unrelated
>>> crash in Blink
>>> ,
>>> since the deprecation rollout was fairly large. It only showed at 10%, 
>>> not
>>> 1%.
>>>
>>
  How would we know of breakage in those 10%? Would that look like users
 filing issues? Something else?


>>> On Mon, Sep 18, 2023 at 3:53 PM Jeffrey Yasskin 
>>> wrote:
>>>
 This should probably be an "Intent to Deprecate and Remove"
 
 rather than an "Intent to Ship". I'll let an API owner say if there's a
 reason to re-send it; probably there isn't.

 On Mon, Sep 18, 2023 at 3:47 PM 'David Adrian' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emailsdadr...@google.com
>
> ExplainerNone
>

 The RFC's introduction at
 https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a
 pretty good explainer for why we should remove SHA-1 signatures.


> Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html
>
> Summary
>
> Chrome is removing support for signature algorithms using SHA-1
> for server signatures during the TLS handshake. This does not affect 
> SHA-1
> support in server certificates, which was already removed, or in 
> client
> certificates, which continues to be supported. SHA-1 can be 
> temporarily
> re-enabled via the temporary InsecureHashesInTLSHandshakesEnabled
> enterprise policy. This policy will be removed in Chrome 123.
>
>
> Blink componentInternals>Network>SSL
> 
>
> Search tagstls , ssl
> , sha1
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> I

Re: [blink-dev] Intent to Experiment: scheduler.yield()

[Chris Harrelson]

LGTM!

On Mon, Sep 25, 2023 at 9:55 AM Scott Haseley  wrote:

> Hi API Owners,
>
> I'd like to extend the initial OT for two milestones (through M120). We've
> fixed some bugs and have had some recent signups, so I'd like to make sure
> folks have enough time to experiment. The initial OT was configured for 4
> milestones, so 2 additional would take this to the max of 6.
>
> Thanks,
> Scott
>
> On Wed, Jun 14, 2023 at 3:02 PM Scott Haseley  wrote:
>
>> On Tue, Jun 13, 2023 at 7:02 PM Domenic Denicola 
>> wrote:
>>
>>> Exciting stuff!!
>>>
>>> > The signal inheritance bit [1], however, would need transpilation
>>> support to propagate the current signal across async (Promise) boundaries.
>>>
>>> I couldn't find where this [1] goes. I'm very interested in this general
>>> area, and questions like whether we propagate by default or not, and how
>>> robust the propagation is to different mechanisms (e.g., not just promises,
>>> but other web platform callbacks as well).
>>>
>>> What's the latest source of information on that, either in our
>>> implementation or in the explainer/spec? I see from the explainer there's a
>>> non-default `signal: "inherit"`, but I couldn't find details on how "the
>>> current task"'s priority is determined and propagated.
>>>
>>
>> Ah, sorry, not sure what happened there; that was probably pointing to
>> the design discussion section
>> 
>> .
>>
>> It's still an open question of whether or not inheritance should be the
>> default here, hoping to work that out soon. I just brain-dumped the current
>> state of things in this doc
>> ,
>> with details about what gets propagated and how that works, along with code
>> pointers. I'm planning to begin the spec work on this soon, in parallel
>> with OT.
>>
>> On Wed, Jun 14, 2023 at 2:53 AM Scott Haseley 
>>> wrote:
>>>
 Contact emailsshase...@chromium.org

 Explainer
 https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md

 SpecificationNone

 Summary

 Provides a method for yielding control to the browser, which can be
 used to break up long tasks. Awaiting the promise returned by
 scheduler.yield() causes the current task to yield, continuing in a new
 browser task. This can be used to improve responsiveness issues caused by
 long tasks. Continuations are prioritized to mitigate performance problems
 of existing alternatives.


 Blink componentBlink>Scheduling>APIs
 

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

 TAG review statusPending

 Risks


 Interoperability and Compatibility

 This is a new feature and will not change existing event loop task
 scheduling, so the main risk is that other browsers might not implement the
 feature. There is an interop challenge, however, that comes with
 prioritization: we want to be specific enough to provide developers
 guarantees and interoperable implementations, but provide enough scheduling
 flexibility for UAs (like the HTML specification does with task
 sources/task queues), which we'll keep in mind while drafting the spec (see
 also https://github.com/WICG/scheduling-apis/issues/67).


 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 The default use (inserting yield points in long tasks) should enable
 Chrome to maintain better performance (responsiveness). There is a risk of
 continuations starving other work, but there are reasonable mitigations,
 e.g. bounding total of prioritized continuations (see also
 https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#preventing-task-starvation-by-continuations
 ).


 Activation

 The feature would benefit from a polyfill so that tasks still yield in
 the case the feature is unavailable. The behavior can be approximated by
 awaiting `scheduler.postTask()` or wrapping `setTimeout(0)` in a promise.
 The signal inheritance bit [1], however, would need transpilation support
 to propagate the current signal across async (Promise) boundaries. But
 developers can alternatively pass the appropriate priority/signal if
 necessary on browsers that don't support the feature.


 Security

 See
 https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy


 WebView application risks

 Does this intent deprecate or change behavior of existing 

Re: [blink-dev] Intent to Experiment: scheduler.yield()

[Scott Haseley]

Hi API Owners,

I'd like to extend the initial OT for two milestones (through M120). We've
fixed some bugs and have had some recent signups, so I'd like to make sure
folks have enough time to experiment. The initial OT was configured for 4
milestones, so 2 additional would take this to the max of 6.

Thanks,
Scott

On Wed, Jun 14, 2023 at 3:02 PM Scott Haseley  wrote:

> On Tue, Jun 13, 2023 at 7:02 PM Domenic Denicola 
> wrote:
>
>> Exciting stuff!!
>>
>> > The signal inheritance bit [1], however, would need transpilation
>> support to propagate the current signal across async (Promise) boundaries.
>>
>> I couldn't find where this [1] goes. I'm very interested in this general
>> area, and questions like whether we propagate by default or not, and how
>> robust the propagation is to different mechanisms (e.g., not just promises,
>> but other web platform callbacks as well).
>>
>> What's the latest source of information on that, either in our
>> implementation or in the explainer/spec? I see from the explainer there's a
>> non-default `signal: "inherit"`, but I couldn't find details on how "the
>> current task"'s priority is determined and propagated.
>>
>
> Ah, sorry, not sure what happened there; that was probably pointing to the 
> design
> discussion section
> 
> .
>
> It's still an open question of whether or not inheritance should be the
> default here, hoping to work that out soon. I just brain-dumped the current
> state of things in this doc
> ,
> with details about what gets propagated and how that works, along with code
> pointers. I'm planning to begin the spec work on this soon, in parallel
> with OT.
>
> On Wed, Jun 14, 2023 at 2:53 AM Scott Haseley 
>> wrote:
>>
>>> Contact emailsshase...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md
>>>
>>> SpecificationNone
>>>
>>> Summary
>>>
>>> Provides a method for yielding control to the browser, which can be used
>>> to break up long tasks. Awaiting the promise returned by scheduler.yield()
>>> causes the current task to yield, continuing in a new browser task. This
>>> can be used to improve responsiveness issues caused by long tasks.
>>> Continuations are prioritized to mitigate performance problems of existing
>>> alternatives.
>>>
>>>
>>> Blink componentBlink>Scheduling>APIs
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/827
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> This is a new feature and will not change existing event loop task
>>> scheduling, so the main risk is that other browsers might not implement the
>>> feature. There is an interop challenge, however, that comes with
>>> prioritization: we want to be specific enough to provide developers
>>> guarantees and interoperable implementations, but provide enough scheduling
>>> flexibility for UAs (like the HTML specification does with task
>>> sources/task queues), which we'll keep in mind while drafting the spec (see
>>> also https://github.com/WICG/scheduling-apis/issues/67).
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> The default use (inserting yield points in long tasks) should enable
>>> Chrome to maintain better performance (responsiveness). There is a risk of
>>> continuations starving other work, but there are reasonable mitigations,
>>> e.g. bounding total of prioritized continuations (see also
>>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#preventing-task-starvation-by-continuations
>>> ).
>>>
>>>
>>> Activation
>>>
>>> The feature would benefit from a polyfill so that tasks still yield in
>>> the case the feature is unavailable. The behavior can be approximated by
>>> awaiting `scheduler.postTask()` or wrapping `setTimeout(0)` in a promise.
>>> The signal inheritance bit [1], however, would need transpilation support
>>> to propagate the current signal across async (Promise) boundaries. But
>>> developers can alternatively pass the appropriate priority/signal if
>>> necessary on browsers that don't support the feature.
>>>
>>>
>>> Security
>>>
>>> See
>>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy
>>>
>>>
>>> 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?
>>>
>>> None
>>>
>>>
>>> Goals for experimentation
>>>
>>> The main goal is to evaluate yielding with 

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

['David Adrian' via blink-dev]

There are approximately 30x TLS connections relative to pageloads, due to
subresources. Once you have a TLS connection open for a main frame, I'm not
sure how many page loads happen across it. Probably a lot, but it's still
dominated by subresources.

In practice, the 0.02% bound appears to have shaken out to sub 0.01%
(0.009%), determined by looking at differences in the "OK" result for
Net.SSL_Connection_Error.

On Tue, Sep 19, 2023 at 8:59 PM Yoav Weiss  wrote:

>
>
> On Wed, Sep 20, 2023 at 12:47 AM David Benjamin 
> wrote:
>
>> On Tue, Sep 19, 2023 at 1:50 AM Yoav Weiss 
>> wrote:
>>
>>> On Tue, Sep 19, 2023 at 7:45 AM Yoav Weiss 
>>> wrote:
>>>
 On Tue, Sep 19, 2023 at 1:35 AM 'Jeffrey Yasskin' via blink-dev <
 blink-dev@chromium.org> wrote:

> On Mon, Sep 18, 2023 at 4:11 PM David Adrian 
> wrote:
>
>> > This should probably be an "Intent to Deprecate and Remove" rather
>> than an "Intent to Ship".
>>
>> You're absolutely right that it should be, unfortunately that's not
>> the subject Chrome Status generated. I'll file an issue.
>>
>
> Oops, yes, you did everything right here. There's already
> https://github.com/GoogleChrome/chromium-dashboard/issues/2749 about
> changing this subject line, and now
> https://github.com/GoogleChrome/chromium-dashboard/issues/3346 to
> align the Chrome Status UI with the launching-features page.
>
> > The RFC's introduction at
>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a
>> pretty good explainer for why we should remove SHA-1 signatures.
>>
>> Agreed. Noting in general, there is a large process mismatch between
>> TLS launches and the Blink launch process, as discussed in
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CmlXjQeNWDI/m/r-AUe0OqAQAJ.
>> That's why this Intent looks a little different.
>>
>
 I wouldn't categorize it as a large process mismatch. But that's an
 orthogonal discussion.


>
>> As for the launch itself, I'll note it's been at 10% on Finch for a
>> couple weeks and everything looks gray, so we should be safe to ramp up 
>> to
>> 100%. The only thing of note was a correlation with an unrelated
>> crash in Blink
>> ,
>> since the deprecation rollout was fairly large. It only showed at 10%, 
>> not
>> 1%.
>>
>
>>>  How would we know of breakage in those 10%? Would that look like users
>>> filing issues? Something else?
>>>
>>>
>> On Mon, Sep 18, 2023 at 3:53 PM Jeffrey Yasskin 
>> wrote:
>>
>>> This should probably be an "Intent to Deprecate and Remove"
>>> 
>>> rather than an "Intent to Ship". I'll let an API owner say if there's a
>>> reason to re-send it; probably there isn't.
>>>
>>> On Mon, Sep 18, 2023 at 3:47 PM 'David Adrian' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emailsdadr...@google.com

 ExplainerNone

>>>
>>> The RFC's introduction at
>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a
>>> pretty good explainer for why we should remove SHA-1 signatures.
>>>
>>>
 Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html

 Summary

 Chrome is removing support for signature algorithms using SHA-1 for
 server signatures during the TLS handshake. This does not affect SHA-1
 support in server certificates, which was already removed, or in client
 certificates, which continues to be supported. SHA-1 can be temporarily
 re-enabled via the temporary InsecureHashesInTLSHandshakesEnabled
 enterprise policy. This policy will be removed in Chrome 123.


 Blink componentInternals>Network>SSL
 

 Search tagstls , ssl
 , sha1
 

 TAG reviewNone

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 At most 0.02% of page loads use the SHA1 fallback. However, we
 cannot disambiguate between a flaky first connection, and actually
 requiring SHA1. We expect the actual amount is lower.

>>>
 Are we thinking that 0.02% is a loose upper bound? Is that correct?

>>>
>> As with anything in TLS, the protocol is client-offer / server-select,
>> which means we pick up all the implications of that. We can measure what
>> the server selects, but that doesn't actually tell

[blink-dev] Intent to Prototype: Mesh2D Canvas API

[Florin Malita]

Contact emailsfmal...@chromium.org

Explainerhttps://github.com/fserb/canvas2D/blob/master/spec/mesh2d.md

SpecificationNone

Summary

A high-performance Canvas 2D triangle mesh API that can be used to
batch-render a large number of textured triangles. This will enable
advanced texture mapping and geometry deformation effects in a 2D context.


Blink componentBlink>Canvas


Motivation

Triangle meshes are a fundamental building block of most low-level graphics
APIs, and their rendering is heavily optimized on modern hardware. They can
represent complex geometries, and provide an efficient mechanism for
texture mapping and morphing. Mapping textures to arbitrary geometries is
of great importance to animation engines (e.g. Lottie, Rive), both as a
direct animation mechanism and as an utility for implementing various
morphological effects. Since Canvas2D does not currently support drawing
triangle meshes, such animation engines are either resorting to inefficient
workarounds or limiting the set of supported features on the web.


Initial public proposal
https://github.com/fserb/canvas2D/blob/master/spec/mesh2d.md

TAG reviewNone

TAG review statusPending

Risks


Interoperability and Compatibility

None


*Gecko*: No signal

*WebKit*: No signal

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

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1486511

Estimated milestones

No milestones specified


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

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/CADgYMVdKYpFR6Cd_yNer-iibO9WR5vqTi9sryBzZiSe7o8-0qw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Bounce Tracking Mitigations

[Ben Kelly]

FYI, we are rolling out bounce tracking mitigations to stable 10% today.
(Again, this only impacts users who are blocking 3P cookies.)  This
intermediate rollout step was added in order to investigate some
regressions that showed up in the 1% stable data.

On Thu, Sep 7, 2023 at 12:29 PM Ben Kelly  wrote:

> Thank you.
>
> FYI, bounce tracking mitigations are rolling out to stable 1% as of today.
>
> On Tue, Sep 5, 2023 at 12:09 PM Chris Harrelson 
> wrote:
>
>> LGTM3
>>
>> On Tue, Sep 5, 2023 at 6:56 AM Ben Kelly  wrote:
>>
>>> Ping for last LGTM or more feedback.  We were hoping to be able to
>>> collect some stable data before TPAC, if possible.
>>>
>>> On Wed, Aug 30, 2023 at 8:45 AM Yoav Weiss 
>>> wrote:
>>>
 LGTM2

 On Tue, Aug 29, 2023 at 5:44 PM Ben Kelly 
 wrote:

> On Tue, Aug 29, 2023 at 1:40 AM Yoav Weiss 
> wrote:
>
>> I agree that WPT infrastructure shouldn't be a blocker when we're
>> following other browsers.
>>
>
> Thank you.
>
> Have y'all tested the mitigation with commonly used
>> authentication/payment flows, to make sure it doesn't break them?
>>
>
> We have been dogfooding and not run into any issues with auth/payment
> flows.  We are also collecting UKM metrics on sites deleted.  I've sent 
> you
> a private email with that information.
>
> The UKM is predominantly advertising, tracking, etc.  There are a
> smattering of auth/ecommerce/etc, but at lower volumes.  The auth issue we
> believe may be related to automatic login scenarios in enterprises (issue
> 36 ),
> which can be largely addressed with enterprise policies.  We also
> integrated webauthn security key taps as interactions in M117 to reduce
> authentication false positives.
>
> Overall, however, we believe that since we only take action when 3P
> cookies are blocked, breakage should be limited.  The 3P cookie default 
> has
> not changed yet, so most users will not be affected.  In addition,
> chromeguard, enterprise policies and other mechanisms can be used to add
> cookie exceptions which bounce tracking mitigations will honor.
>
> Ultimately, many sites will need to adapt to a new normal when the 3P
> cookie setting default changes.  That will need to include that bounce
> tracking is not an acceptable replacement.  We would like to ship bounce
> tracking mitigations gated on 3P cookie permissions so that when sites
> perform 3P cookie deprecation testing they see the new bounce tracking
> behavior as well.
>

 Thanks for outlining your motivations! Going ahead with this change
 before the 3P cookie deprecation but 3P cookie blocking makes perfect 
 sense!


>
>
>>
>> On Mon, Aug 28, 2023 at 11:08 PM Mike Taylor 
>> wrote:
>>
>>> LGTM1 to ship, as long as we fast follow with doing the work to
>>> define
>>> and ship webdriver extensions in order to make this testable in WPT.
>>>
>>> (I don't think your team should be blocked on shipping because other
>>> browsers who already shipped the feature didn't do that work.)
>>>
>>> On 8/21/23 3:44 PM, Christian Biesinger wrote:
>>> > On Mon, Aug 21, 2023 at 3:25 PM Ben Kelly 
>>> wrote:
>>> >>
>>> >>
>>> >> On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor <
>>> miketa...@chromium.org> wrote:
>>> >>> On 8/21/23 11:09 AM, Ben Kelly wrote:
>>> >>>
>>> >>> On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss <
>>> yoavwe...@chromium.org> wrote:
>>>  Thanks for working on this important problem!
>>> 
>>>  On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly <
>>> wanderv...@chromium.org> wrote:
>>> > Sorry, it seems I left off the signals section of the template:
>>> >
>>> > Firefox: No signal (
>>> https://github.com/mozilla/standards-positions/issues/835)
>>> 
>>>  Firefox folks seem tentatively supportive, but have WPT
>>> questions. Can you address them?
>>> >>>
>>> >>> I'm checking without our WPT folks to try to understand what
>>> mozilla is suggesting.  I'm not familiar with web-driver functions at 
>>> all,
>>> so not quite sure yet how feasible this is.
>>> >>>
>>> >>> My read on bvandersloot's comment is that he's asking for a less
>>> generic version
>>> https://github.com/web-platform-tests/wpt/issues/17489 to make this
>>> testable (which you've already linked below). Exposing endpoints for
>>> advancing time seems to have more use cases than bounce 
>>> tracking-specific
>>> webdriver endpoints, IMHO - but that's a discussion that should probably
>>> happen in the relevant WG.
>>> >>>
>>> >>> See https://github.com/web-platform-tests/rfcs for the process
>>> to propose extending the testdr

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

['W. James MacLean' via blink-dev]

No, I think you need to get the server to send the header. Once you get as
far as the meta tags, the origin's isolation state has already been
decided. I'm not an expert on servers, but my experience in specifying
headers to be sent with static pages is to edit the .htaccess file in the
directory with the content, and include

HEADER add Origin-Agent-Cluster: ?0

But the exact details will depend on your setup.

For Apache: https://httpd.apache.org/docs/2.4/howto/htaccess.html

[image: GoogleAnimated.gif]

⭘ W. James MacLean

⭘ Software Engineer

⭘ Google Waterloo
,
Canada


On Tue, 19 Sept 2023 at 23:40, Madanagopal Damodharan <
dmadanago...@gmail.com> wrote:

> This helped us identify the response that did not have the header. We
> noticed that we have a static html called signon.html as our first entry
> into the application. Since this is a static html, our servlet changes to
> add response header does not hit when users invoke this signon.html. I
> think Chrome puts this origin into Origin-keyed cluster at this point and
> hence when users login and encounter document.domain, they get the error
> blocked frame error.
>
> meta tags with http-equiv does not recognize this custom response header
> Origin-Agent-Cluster. Is there a way to add response headers in a static
> html page response?
>
> On Wednesday, 13 September 2023 at 22:49:00 UTC+5:30 W. James MacLean
> wrote:
>
>> Perhaps try this:
>> 1) open a new tab page (or about:blank if you prefer)
>> 2) right-click and select "Inspect" at the bottom of the popup menu
>> 3) in the DevTools menu at the top, click "Network"
>> 4) then check the "Preserve Logs" checkbox in the row under that menu
>> 5) finally, manually type the url for your app/site in the url bar
>>
>> As your content loads, the DevTools window will populate with an (in
>> order) list of all the network transactions. You can click on each element
>> in the list and see the response headers for each request. This should help
>> you determine which request is missing the Origin-Agent-Cluster:?0 header
>> and causing the origin keying to be applied for the tab.
>>
>> Let me know if that helps.
>>
>>
>> [image: GoogleAnimated.gif]
>>
>> ⭘ W. James MacLean
>>
>> ⭘ Software Engineer
>>
>> ⭘ Google Waterloo
>> ,
>> Canada
>>
>>
>>
>> On Wed, 13 Sept 2023 at 12:44, Madanagopal Damodharan <
>> dmadan...@gmail.com> wrote:
>>
>>> An update on the issue I am facing: We have a static html in web server
>>> called signon.html. Users access this static html page first which has a
>>> refresh directive with content=1. As soon as the user invokes this html
>>> page first time from the origin, this redirects to a login form page. This
>>> response contains the header too. But still chrome console says the origin
>>> was in origin-keyed cluster. If I change the refresh directive content=5,
>>> it takes 5 sec to redirect from signon.html to login form, this time I
>>> don't get the console warning. Now I can login and dont see any errors. I
>>> am not sure why the refresh directive 5 works but not 1. Is it because
>>> Chrome could not capture request and place the origin in appropriate
>>> cluster within its 1 second?
>>>
>>> Modified the CONTENT=5 from CONTENT=1 in the below line to get it
>>> working - 
>>>
>>> Any thoughts?
>>>
>>> On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal Damodharan
>>> wrote:
>>>
>>> Thanks for response. In my case, I am getting the error when a new tab
>>> is opened from an existing tab. My existing tab did not throw this error
>>> whereas the new tab shows the error on the first request itself. So based
>>> on what you mentioned, my parent tab should have been part of Origin-Keyed
>>> cluster, right? I am seeing console warning as follows on my new tab that
>>> was opened from an existing tab:
>>>
>>> "The page did not request an Origin-Keyed agent cluster but was put in
>>> one anyway because the origin had previously been placed in an origin-keyed
>>> agent cluster. Update your headers to uniformly request origin-keying for
>>> all pages on the origin"
>>>
>>> I am currently trying to figure out which server response did not have
>>> the header ""Origin-Agent-Cluster: ?0" that led my pages to get in
>>> origin-keyed cluster. Is there a way (debug tool etc) I can check which
>>> response decided Origin-Keying? I think this will be crucial for
>>> applications to debug the issues.
>>>
>>> One other question: My parent tab has a wss (web socket) request that
>>> does not have its response with this OAC header. Do we need the header in
>>> wss response as well?
>>>
>>>
>>> On Thursday, 7 September 2023 at 23:00:32 UTC+5:30 W. James MacLean
>>> wrote:
>>>
>>> If the application is getting loaded inside a tab that has previously
>>> loaded other pages from the same origin (i.e. pages not part of the app)
>>> that do not have 

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Kyra Seevers]

Hi all,

Wanted to keep the thread updated and confirm that we have not shipped to
Stable 100% yet. We will be delaying another day or two due to
internal delays.

Thanks,
Kyra

On Wed, Sep 20, 2023 at 8:53 AM Kyra Seevers  wrote:

> Hi Chinmay,
>
> Thanks for reaching out! Due to internal delays, we won't be rolling out
> to Stable 100% likely until the end of the week or the beginning of next
> week. I'll keep the thread updated with any further delays.
>
> Thanks,
> Kyra
>
> On Tue, Sep 19, 2023 at 7:50 PM Chinmay Manchanda 
> wrote:
>
>> Hi Kyra,
>>
>> Do we have an update on what time the feature will be rolled out today?
>>
>> Cheers,
>> Chinmay
>>
>> On Tuesday, 12 September 2023 at 18:06:57 UTC+10 Kyra Seevers wrote:
>>
>>> Hi Muhammad,
>>>
>>> I have filed this bug for the issue:
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1481485. We would
>>> appreciate it if you could describe your set-up with more detail in this
>>> bug. Have you registered for the deprecation trial described here?:
>>> https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/
>>>
>>> Thanks,
>>> Kyra
>>>
>>> On Mon, Sep 11, 2023 at 10:48 PM Muhammad Ahmed Mallick <
>>> amal...@folio3.com> wrote:
>>>
 Hi All,
 I'm also facing challenges with the current situation. We're loading my
 own website within the Chrome extension, and we manage the user's login
 state (tokens) on my website. The extension's iframe is supposed to
 retrieve the token from local storage, but it's currently broken. It's not
 feasible to ask the user to log in twice just to access the extension's
 content.

 Please let me know if there is any solution to get it fixed asap.

 Thanks
 Ahmed

 On Wednesday, September 6, 2023 at 2:03:55 PM UTC+5 Kyra Seevers wrote:

> Hi all,
>
> Another quick update: we began the rollout to 50% stable today.
>
> We will roll-out to 100% of Stable users on approximately Sept. 20th,
> 2023.
>
> Thanks,
> Kyra
>
> On Thu, Aug 24, 2023 at 3:48 PM Mike Taylor 
> wrote:
>
>> I've filed
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1475667 - it
>> would be great if you both could give more context about your embedded
>> application, and how you deal with Safari and Firefox as comments in the
>> bug (same goes for anyone else facing this issue).
>>
>> thanks,
>> Mike
>> On 8/24/23 8:45 AM, Tim Williams wrote:
>>
>> We have the same situation as Junji here.
>> For us, it means that our solution would be broken across all
>> websites since the platforms are using our iframe URL and we have 0 
>> ability
>> to inject code at their top Domain (nor do we want to).
>> On Wednesday, August 23, 2023 at 8:33:57 PM UTC+3 Junji Genesys wrote:
>>
>>> Our application has no access to the top-level context, so there is
>>> no way for us to include our third-party trial script in the top-level
>>> context.
>>> We basically provide Salesforce with our embedded client URL, and
>>> they use it to load and embed our client in their iframe.
>>>
>>> On Wed, Aug 23, 2023 at 11:30 AM Mike Taylor 
>>> wrote:
>>>
 Yes, if you sign up for a 3rd party token and inject that into the
 site embedding your iframe before your iframe is created, that will 
 give
 you access to unpartitioned storage (until the Deprecation Trial 
 expires).

 Here's a demo that injects an 3P origin trial token then creates an
 iframe:

 https://rogue-lace-join.glitch.me/

 And the relevant source files:

 https://glitch.com/edit/#!/rogue-lace-join?path=index.html%3A9%3A8
 https://miketaylr.com/misc/3pspdt.js

 Feel free to reach out to me off-list to discuss more or if you
 have any further questions.
 On 8/22/23 11:40 PM, Yoav Weiss wrote:

 Is your application running script in the top level context? Since
 the deprecation trial is implemented as a third-party origin trial, 
 you may
 be able to sign up as a third party.

 On Tue, Aug 22, 2023, 23:48 Junji Genesys 
 wrote:

> Hello Kyra,
>
> Thank you for communicating about the rollout plan for the storage
> partitioning.
>
> We've found that the new storage partitioning behavior has
> impacted our product, which is a web client application embedded in an
> iframe inside Salesforce and provides call center agents 
> functionality such
> as handling phone calls. We use browser-based phone (WebRTC phone) 
> that can
> pop out as a separate window, which communicates with the embedded 
> client
> frame via localStorage and BroadcastChannel. The new st