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

[Yoav Weiss]

On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth 
wrote:

> Hey folks,
>
> I'll be spinning up a thread with some internal folks here at Salesforce
> to start doing some scans of code to determine utilization. Has this been
> added to the reporting API for deprecation to possibly capture live hits
> that way as well?
>

I believe the intent is asking to add those as part of the deprecation
period, but that hasn't happened yet.


>
> I'll follow up on what I find and that will influence my opinion on
> removal timeline.
>
> ~Greg
>
> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:
>
>> Note that Daniel has already landed the enterprise policy for this in
>> https://chromium-review.googlesource.com/c/chromium/src/+/3317349
>> (99.0.4759.0).
>>
>> Charlie
>>
>> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  wrote:
>>
>>> > This probably requires an Enterprise Policy, to reduce the risk for
>>> managed installs. +bheenan@ for opinions on that front.
>>>
>>> I agree, this looks like a breaking change according to
>>> go/chrome-enterprise-friendly and therefore needs a policy.
>>> Instructions for implementing a policy are here:
>>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>> if you haven't done it before, and the enterprise team is happy to help if
>>> anything seems confusing. Having this implemented as a "soft removal" with
>>> a temporary policy escape hatch significantly reduces enterprise risk,
>>> since even if we are surprised by a use case hiding behind many
>>> enterprises' tendency to turn off metrics, those users can
>>> break-fix themselves immediately while staying on the latest version.
>>>
>>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 
>>> wrote:
>>>
 Hey Daniel!

 While searching for this intent review, I stumbled upon
 https://developer.chrome.com/blog/immutable-document-domain/
 That's a useful piece of documentation! Thanks +Eiji Kitamura!!

 This intent was just discussed at the API owner meeting (where Chris,
 Rego, Daniel, Philip, Alex, MikeT and myself were present).
 This change seems risky in terms of potential breakage when looking at
 our stats, and that's even before talking about enterprises, where a lot of
 the API owners feel the risk is even higher.

 Given that, here's a few potential next steps to try and reduce that
 risk:

- UKM and outreach to specific large users of the API can maybe
help drive the usage down.
- A deprecation period of 3 milestones feels a bit short here. Is
the expectation that turning on the opt-out header can be done under 
 that
period?
- A report-only mode could have allowed sites to try and enable
this, without risking actual breakage for their documents/properties 
 that
use document.domain. This is doubly true for platforms that want to warn
their customers about this upcoming deprecation, but without taking 
 risks
on their behalf. At the same time, it is true that they could collect
deprecation reports (thanks for adding those!) instead during the
deprecation period, which can be considered an on-by-default report-only
mode. Can y'all add specific guidance on deprecation reports to the
documentation?
-  It'd be helpful to reach out to enterprise folks and see what
their responses may be for this. +Greg Whitworth.
- This probably requires an Enterprise Policy, to reduce the risk
for managed installs. +bheenan@ for opinions on that front.
- Is there a plan to eventually remove the opt-out option? Or is it
the plan to have it in place permanently?

 Cheers,
 Yoav


 On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:

> On 12/16/21 5:52 PM, Charlie Reis wrote:
>
>
>
> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
> blin...@chromium.org> wrote:
>
>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
>> wrote:
>>
>>> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>>>
>>> It seems more or less everyone agrees on this being a good thing, so
>>> it mainly comes down to web compatibility.
>>>
>>> How much of the web will break, and how badly. The numbers
>>> mentioned, 0.5% of sites set document.domain, 0.05% seem to depend on
>>> document.domain, are quite high. One thing I didn't quite pick up is 
>>> what
>>> happens if you try to set document.domain when it's not settable. Will 
>>> it
>>> silently pretend to work, or will that also be a possible break point?
>>>
>>> I would be surprised if it didn't behave the same as setting an
>>> arbitrary expando on `document` - we should be safe there.
>>>
>>
>> Almost. The error handling is mostly the same. But while a foreign
>> attribute 

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

[Greg Whitworth]

Hey folks,

I'll be spinning up a thread with some internal folks here at Salesforce to 
start doing some scans of code to determine utilization. Has this been 
added to the reporting API for deprecation to possibly capture live hits 
that way as well?

I'll follow up on what I find and that will influence my opinion on removal 
timeline.

~Greg

On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:

> Note that Daniel has already landed the enterprise policy for this in 
> https://chromium-review.googlesource.com/c/chromium/src/+/3317349 
> (99.0.4759.0).
>
> Charlie
>
> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  wrote:
>
>> > This probably requires an Enterprise Policy, to reduce the risk for 
>> managed installs. +bheenan@ for opinions on that front.
>>
>> I agree, this looks like a breaking change according to 
>> go/chrome-enterprise-friendly and therefore needs a policy. Instructions 
>> for implementing a policy are here: 
>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>  
>> if you haven't done it before, and the enterprise team is happy to help if 
>> anything seems confusing. Having this implemented as a "soft removal" with 
>> a temporary policy escape hatch significantly reduces enterprise risk, 
>> since even if we are surprised by a use case hiding behind many 
>> enterprises' tendency to turn off metrics, those users can 
>> break-fix themselves immediately while staying on the latest version.
>>
>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  wrote:
>>
>>> Hey Daniel!
>>>
>>> While searching for this intent review, I stumbled upon 
>>> https://developer.chrome.com/blog/immutable-document-domain/ 
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where Chris, 
>>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking at 
>>> our stats, and that's even before talking about enterprises, where a lot of 
>>> the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that 
>>> risk:
>>>
>>>- UKM and outreach to specific large users of the API can maybe help 
>>>drive the usage down.
>>>- A deprecation period of 3 milestones feels a bit short here. Is 
>>>the expectation that turning on the opt-out header can be done under 
>>> that 
>>>period?
>>>- A report-only mode could have allowed sites to try and enable 
>>>this, without risking actual breakage for their documents/properties 
>>> that 
>>>use document.domain. This is doubly true for platforms that want to warn 
>>>their customers about this upcoming deprecation, but without taking 
>>> risks 
>>>on their behalf. At the same time, it is true that they could collect 
>>>deprecation reports (thanks for adding those!) instead during the 
>>>deprecation period, which can be considered an on-by-default report-only 
>>>mode. Can y'all add specific guidance on deprecation reports to the 
>>>documentation?
>>>-  It'd be helpful to reach out to enterprise folks and see what 
>>>their responses may be for this. +Greg Whitworth.
>>>- This probably requires an Enterprise Policy, to reduce the risk 
>>>for managed installs. +bheenan@ for opinions on that front.
>>>- Is there a plan to eventually remove the opt-out option? Or is it 
>>>the plan to have it in place permanently?
>>>
>>> Cheers,
>>> Yoav
>>>
>>>
>>> On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:
>>>
 On 12/16/21 5:52 PM, Charlie Reis wrote:



 On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
 blin...@chromium.org> wrote:

> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor  
> wrote:
>
>> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>>
>> It seems more or less everyone agrees on this being a good thing, so 
>> it mainly comes down to web compatibility.
>>
>> How much of the web will break, and how badly. The numbers mentioned, 
>> 0.5% of sites set document.domain, 0.05% seem to depend on 
>> document.domain, 
>> are quite high. One thing I didn't quite pick up is what happens if you 
>> try 
>> to set document.domain when it's not settable. Will it silently pretend 
>> to 
>> work, or will that also be a possible break point?
>>
>> I would be surprised if it didn't behave the same as setting an 
>> arbitrary expando on `document` - we should be safe there.
>>
>
> Almost. The error handling is mostly the same. But while a foreign 
> attribute on document would return the new value, document.domain (when 
> in 
> an origin-keyed agent cluster) does not.
>
> So:
>   document.foo = "bla"
>   document.foo  // Returns "bla".
>
>   document.domain 

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

[Charlie Reis]

Note that Daniel has already landed the enterprise policy for this in
https://chromium-review.googlesource.com/c/chromium/src/+/3317349
(99.0.4759.0).

Charlie

On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  wrote:

> > This probably requires an Enterprise Policy, to reduce the risk for
> managed installs. +bheenan@ for opinions on that front.
>
> I agree, this looks like a breaking change according to
> go/chrome-enterprise-friendly and therefore needs a policy. Instructions
> for implementing a policy are here:
> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
> if you haven't done it before, and the enterprise team is happy to help if
> anything seems confusing. Having this implemented as a "soft removal" with
> a temporary policy escape hatch significantly reduces enterprise risk,
> since even if we are surprised by a use case hiding behind many
> enterprises' tendency to turn off metrics, those users can
> break-fix themselves immediately while staying on the latest version.
>
> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 
> wrote:
>
>> Hey Daniel!
>>
>> While searching for this intent review, I stumbled upon
>> https://developer.chrome.com/blog/immutable-document-domain/
>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>
>> This intent was just discussed at the API owner meeting (where Chris,
>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>> This change seems risky in terms of potential breakage when looking at
>> our stats, and that's even before talking about enterprises, where a lot of
>> the API owners feel the risk is even higher.
>>
>> Given that, here's a few potential next steps to try and reduce that risk:
>>
>>- UKM and outreach to specific large users of the API can maybe help
>>drive the usage down.
>>- A deprecation period of 3 milestones feels a bit short here. Is the
>>expectation that turning on the opt-out header can be done under that
>>period?
>>- A report-only mode could have allowed sites to try and enable this,
>>without risking actual breakage for their documents/properties that use
>>document.domain. This is doubly true for platforms that want to warn their
>>customers about this upcoming deprecation, but without taking risks on
>>their behalf. At the same time, it is true that they could collect
>>deprecation reports (thanks for adding those!) instead during the
>>deprecation period, which can be considered an on-by-default report-only
>>mode. Can y'all add specific guidance on deprecation reports to the
>>documentation?
>>-  It'd be helpful to reach out to enterprise folks and see what
>>their responses may be for this. +Greg Whitworth.
>>- This probably requires an Enterprise Policy, to reduce the risk for
>>managed installs. +bheenan@ for opinions on that front.
>>- Is there a plan to eventually remove the opt-out option? Or is it
>>the plan to have it in place permanently?
>>
>> Cheers,
>> Yoav
>>
>>
>> On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:
>>
>>> On 12/16/21 5:52 PM, Charlie Reis wrote:
>>>
>>>
>>>
>>> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
 wrote:

> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>
> It seems more or less everyone agrees on this being a good thing, so
> it mainly comes down to web compatibility.
>
> How much of the web will break, and how badly. The numbers mentioned,
> 0.5% of sites set document.domain, 0.05% seem to depend on 
> document.domain,
> are quite high. One thing I didn't quite pick up is what happens if you 
> try
> to set document.domain when it's not settable. Will it silently pretend to
> work, or will that also be a possible break point?
>
> I would be surprised if it didn't behave the same as setting an
> arbitrary expando on `document` - we should be safe there.
>

 Almost. The error handling is mostly the same. But while a foreign
 attribute on document would return the new value, document.domain (when in
 an origin-keyed agent cluster) does not.

 So:
   document.foo = "bla"
   document.foo  // Returns "bla".

   document.domain = "bla"  // Throws SecurityException.

   // On a domain www.host.com, site-keyed agent cluster (current
 default)
   document.domain = "host.com"  // Succeeds.
   document.domain;  // returns "host.com".

   // On a domain www.host.com, origin-keyed agent cluster (future
 default)
   document.domain = "host.com"  // Doesn't throw. Doesn't do anything
 else either.
   document.domain;  // Still returns www.host.com.

 Risks: Interoperability and Compatibility
>
> * No interoperability risks. *
> Compatibility risk exists, but is fairly

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

['Brandon Heenan' via blink-dev]

> This probably requires an Enterprise Policy, to reduce the risk for
managed installs. +bheenan@ for opinions on that front.

I agree, this looks like a breaking change according to
go/chrome-enterprise-friendly and therefore needs a policy. Instructions
for implementing a policy are here:
https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
if you haven't done it before, and the enterprise team is happy to help if
anything seems confusing. Having this implemented as a "soft removal" with
a temporary policy escape hatch significantly reduces enterprise risk,
since even if we are surprised by a use case hiding behind many
enterprises' tendency to turn off metrics, those users can
break-fix themselves immediately while staying on the latest version.

On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  wrote:

> Hey Daniel!
>
> While searching for this intent review, I stumbled upon
> https://developer.chrome.com/blog/immutable-document-domain/
> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>
> This intent was just discussed at the API owner meeting (where Chris,
> Rego, Daniel, Philip, Alex, MikeT and myself were present).
> This change seems risky in terms of potential breakage when looking at our
> stats, and that's even before talking about enterprises, where a lot of the
> API owners feel the risk is even higher.
>
> Given that, here's a few potential next steps to try and reduce that risk:
>
>- UKM and outreach to specific large users of the API can maybe help
>drive the usage down.
>- A deprecation period of 3 milestones feels a bit short here. Is the
>expectation that turning on the opt-out header can be done under that
>period?
>- A report-only mode could have allowed sites to try and enable this,
>without risking actual breakage for their documents/properties that use
>document.domain. This is doubly true for platforms that want to warn their
>customers about this upcoming deprecation, but without taking risks on
>their behalf. At the same time, it is true that they could collect
>deprecation reports (thanks for adding those!) instead during the
>deprecation period, which can be considered an on-by-default report-only
>mode. Can y'all add specific guidance on deprecation reports to the
>documentation?
>-  It'd be helpful to reach out to enterprise folks and see what their
>responses may be for this. +Greg Whitworth.
>- This probably requires an Enterprise Policy, to reduce the risk for
>managed installs. +bheenan@ for opinions on that front.
>- Is there a plan to eventually remove the opt-out option? Or is it
>the plan to have it in place permanently?
>
> Cheers,
> Yoav
>
>
> On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:
>
>> On 12/16/21 5:52 PM, Charlie Reis wrote:
>>
>>
>>
>> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
>>> wrote:
>>>
 On 12/14/21 11:35 AM, Daniel Bratell wrote:

 It seems more or less everyone agrees on this being a good thing, so it
 mainly comes down to web compatibility.

 How much of the web will break, and how badly. The numbers mentioned,
 0.5% of sites set document.domain, 0.05% seem to depend on document.domain,
 are quite high. One thing I didn't quite pick up is what happens if you try
 to set document.domain when it's not settable. Will it silently pretend to
 work, or will that also be a possible break point?

 I would be surprised if it didn't behave the same as setting an
 arbitrary expando on `document` - we should be safe there.

>>>
>>> Almost. The error handling is mostly the same. But while a foreign
>>> attribute on document would return the new value, document.domain (when in
>>> an origin-keyed agent cluster) does not.
>>>
>>> So:
>>>   document.foo = "bla"
>>>   document.foo  // Returns "bla".
>>>
>>>   document.domain = "bla"  // Throws SecurityException.
>>>
>>>   // On a domain www.host.com, site-keyed agent cluster (current
>>> default)
>>>   document.domain = "host.com"  // Succeeds.
>>>   document.domain;  // returns "host.com".
>>>
>>>   // On a domain www.host.com, origin-keyed agent cluster (future
>>> default)
>>>   document.domain = "host.com"  // Doesn't throw. Doesn't do anything
>>> else either.
>>>   document.domain;  // Still returns www.host.com.
>>>
>>> Risks: Interoperability and Compatibility

 * No interoperability risks. *
 Compatibility risk exists, but is fairly small as document.domain is an
 already deprecated feature. We’ve detailed UKM metrics in place and are
 planning to reach out to top users as soon as we’ve LGTMs for the plan.

 As Daniel mentioned, I think the compat risk should be considered to be
 higher, despite this being deprecated for a long time.

>>>
>>> Yes, agreed.

Re: [blink-dev] Intent to Experiment: Multi-Screen Window Placement

['Mike Wasserman' via blink-dev]

[BCC blink-dev]

Hi, Thanks for reaching out. The Origin Trial has ended, but developers can
still test these features.

   - Either enable:
   chrome://flags/#enable-experimental-web-platform-features
   - Or run chrome with the command
   line flag: --enable-blink-features=WindowPlacement

Feel free to submit issues on GitHub
 and watch ChromeStatus
 for status updates.

Thanks,
Mike


On Thu, Jan 13, 2022 at 9:37 AM Thomas Schaaf 
wrote:

> Hello,
>
> right now it's not possible to register for the experiment anymore. Would
> it be possible to open registration again? Or will the feature be changed
> so that it is available behind a feature flag?
>
> Thomas
>
> Ajay Rahatekar schrieb am Mittwoch, 18. August 2021 um 23:18:46 UTC+2:
>
>> Ty, Chris.
>>
>> On Wed, Aug 18, 2021 at 2:17 PM Chris Harrelson 
>> wrote:
>>
>>> Sure thing. LGTM
>>>
>>> On Wed, Aug 18, 2021 at 2:12 PM 'Ajay Rahatekar' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Hi All,

 Due to the new Chrome 4 week cycle release cycle and the team expecting
 to land so CLs during the OT, can we please have approval to extend the OT
 by one milestone to M96? The new OT window would be M93-M96

 Thanks in advance,

 Ajay


 On Thursday, July 1, 2021 at 12:34:21 PM UTC-7 Mike West wrote:

> LGTM to experiment from M93-M95.
>
> Good luck!
>
> -mike
>
>
> On Thu, Jul 1, 2021 at 9:30 PM Mike Wasserman  wrote:
>
>> Thanks Mike and Yoav,
>>
>> Yes, M93-M95 is our target timeframe for this second OT.
>> As Tom said, we made nontrivial API shape (and implementation)
>> changes to address feedback from the first OT.
>> See CHANGES.md
>> , 
>> the
>> spec PR , a slide
>> 
>>  (some
>> of that deck is outdated), and a google-internal (for now) shape
>> change
>> 
>>  design
>> doc.
>> We want to ensure these changes satisfy partner needs and work well
>> across a variety of OS+display configuration environments.
>>
>> Let me know if you have any questions or requests. Thanks!
>> Mike
>>
>> On Thu, Jul 1, 2021 at 11:36 AM Mike West  wrote:
>>
>>> I appreciate the work y'all have done to satisfy folks from the
>>> security and privacy teams around the UX of this feature. I'm 
>>> comfortable
>>> with y'all taking another stab at getting feedback from developers.
>>>
>>> What timeline are you requesting for experimentation? M93-M95ish?
>>>
>>> -mike
>>>
>>>
>>> On Tue, Jun 29, 2021 at 10:29 AM 'Thomas Steiner' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Hi Yoav,

 The API changes are documented in
 https://github.com/webscreens/window-placement/blob/main/CHANGES.md
 (and https://github.com/GoogleChrome/web.dev/pull/5591). The tl;dr
 is that the API shape and ergonomics have changed, based on the 
 feedback
 from the first origin trial.

 Cheers,
 Tom


 On Mon, Jun 28, 2021 at 5:48 PM Yoav Weiss 
 wrote:

> Thanks for working on a better multi-screen experience! I know I
> could use that as a user :)
>
> What's the relationship between this and the previous I2E
> ?
> Has the API changed since? Any learnings from the previous trial that 
> were
> incorporated into the current design?
>
> On Fri, Jun 25, 2021 at 10:49 PM 'Mike Wasserman' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Contact emailsm...@chromium.org, en...@chromium.org
>>
>> Explainerhttps://github.com/webscreens/window-placement
>>
>> Specificationhttps://webscreens.github.io/window-placement/
>>
>> Design docshttps://web.dev/multi-screen-window-placement/
>>
>> Summary
>>
>> Adds new screen information APIs and makes incremental
>> improvements to existing window placement APIs, allowing web 
>> applications
>> to offer compelling multi-screen experiences. The existing singular
>> window.screen offers a limited view of available screen space, and 
>> window
>> placement functions generally clamp bounds to the current screen. 
>> This
>> feature unlocks modern multi-screen workspaces for web applica

Re: [blink-dev] Fwd: V8 typeof(Function(str)) is undefined

[K. Moon]

I see you cross-posted this question to the v8-dev mailing list, which
probably is a better venue for asking this question. Blink refers to the
HTML engine in Chromium, and is not directly related to JavaScript
execution.

On Thu, Jan 13, 2022 at 9:35 AM victoria yang 
wrote:

>
>
> Hi,
>   Recently I encountered an issue in V8.
>
> *Issue*:
> typeof(Function(str)) is undefined
>
> *Env:*
> *Step1*: In One Isolate, I create Context A (Run Common JS bundle ) and
> Context B(Run Business JS Bundle), and set Same SecurityToken.
>
> *Step2*:
> In ContextA  had JS code Below :
>
>
>  testFunction(){
>   let tmpFunc = *Function*("(function test(\n) {\nreturn 7;\n})\n");
>   console.log(*typeof tmpFunc*);
> }
>
>
> on ContextA, run testFunction(), console result is '*function*'
>
> *Step3*:
> In ContextB, call testFunction in ContextA
> console result is '*undefined*',
> and run tmpFunc(), report Exception '* is not a function*'
>
>
> And For Object.create() 、Object.is() and so on shows OK. Only
> StringToFunction shows error.
> Do you know Why it causes such an issue? Any Advice ?
>
>
> Pls,help.
> Thank you for your time and I look forward to your reply.
>
> --
> 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/CAP96edPrJ%2Bdm0dysQzFwiE7m_4En_ZhkYC60D8%2BtBaWCGU2_kg%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/CACwGi-44%3D99aoMu0YxqkrGXG1e0BMKXH7M4Uv40VJoZUpEw7Zw%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Multi-Screen Window Placement

[Thomas Schaaf]

Hello,

right now it's not possible to register for the experiment anymore. Would 
it be possible to open registration again? Or will the feature be changed 
so that it is available behind a feature flag?

Thomas

Ajay Rahatekar schrieb am Mittwoch, 18. August 2021 um 23:18:46 UTC+2:

> Ty, Chris.
>
> On Wed, Aug 18, 2021 at 2:17 PM Chris Harrelson  
> wrote:
>
>> Sure thing. LGTM
>>
>> On Wed, Aug 18, 2021 at 2:12 PM 'Ajay Rahatekar' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hi All,
>>>
>>> Due to the new Chrome 4 week cycle release cycle and the team expecting 
>>> to land so CLs during the OT, can we please have approval to extend the OT 
>>> by one milestone to M96? The new OT window would be M93-M96
>>>
>>> Thanks in advance,
>>>
>>> Ajay
>>>
>>>
>>> On Thursday, July 1, 2021 at 12:34:21 PM UTC-7 Mike West wrote:
>>>
 LGTM to experiment from M93-M95.

 Good luck!

 -mike


 On Thu, Jul 1, 2021 at 9:30 PM Mike Wasserman  wrote:

> Thanks Mike and Yoav,
>
> Yes, M93-M95 is our target timeframe for this second OT.
> As Tom said, we made nontrivial API shape (and implementation) changes 
> to address feedback from the first OT.
> See CHANGES.md 
> , 
> the 
> spec PR , a slide 
> 
>  (some 
> of that deck is outdated), and a google-internal (for now) shape 
> change 
> 
>  design 
> doc.
> We want to ensure these changes satisfy partner needs and work well 
> across a variety of OS+display configuration environments.
>
> Let me know if you have any questions or requests. Thanks!
> Mike
>
> On Thu, Jul 1, 2021 at 11:36 AM Mike West  wrote:
>
>> I appreciate the work y'all have done to satisfy folks from the 
>> security and privacy teams around the UX of this feature. I'm 
>> comfortable 
>> with y'all taking another stab at getting feedback from developers.
>>
>> What timeline are you requesting for experimentation? M93-M95ish?
>>
>> -mike
>>
>>
>> On Tue, Jun 29, 2021 at 10:29 AM 'Thomas Steiner' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hi Yoav,
>>>
>>> The API changes are documented in 
>>> https://github.com/webscreens/window-placement/blob/main/CHANGES.md 
>>> (and https://github.com/GoogleChrome/web.dev/pull/5591). The tl;dr 
>>> is that the API shape and ergonomics have changed, based on the 
>>> feedback 
>>> from the first origin trial.
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>> On Mon, Jun 28, 2021 at 5:48 PM Yoav Weiss  
>>> wrote:
>>>
 Thanks for working on a better multi-screen experience! I know I 
 could use that as a user :)

 What's the relationship between this and the previous I2E 
 ? 
 Has the API changed since? Any learnings from the previous trial that 
 were 
 incorporated into the current design?

 On Fri, Jun 25, 2021 at 10:49 PM 'Mike Wasserman' via blink-dev <
 blin...@chromium.org> wrote:

> Contact emailsm...@chromium.org, en...@chromium.org
>
> Explainerhttps://github.com/webscreens/window-placement
>
> Specificationhttps://webscreens.github.io/window-placement/
>
> Design docshttps://web.dev/multi-screen-window-placement/
>
> Summary
>
> Adds new screen information APIs and makes incremental 
> improvements to existing window placement APIs, allowing web 
> applications 
> to offer compelling multi-screen experiences. The existing singular 
> window.screen offers a limited view of available screen space, and 
> window 
> placement functions generally clamp bounds to the current screen. 
> This 
> feature unlocks modern multi-screen workspaces for web applications.
>
>
> Blink componentUI>Browser>WebAppInstalls 
> 
>
> Search tagswindow placement 
> , 
> screen 
> enumeration 
> 
> , window , open 
> , moveTo 
> , moveBy 
>

[blink-dev] Fwd: V8 typeof(Function(str)) is undefined

[victoria yang]

Hi,
  Recently I encountered an issue in V8.

*Issue*:
typeof(Function(str)) is undefined

*Env:*
*Step1*: In One Isolate, I create Context A (Run Common JS bundle ) and
Context B(Run Business JS Bundle), and set Same SecurityToken.

*Step2*:
In ContextA  had JS code Below :


 testFunction(){
  let tmpFunc = *Function*("(function test(\n) {\nreturn 7;\n})\n");
  console.log(*typeof tmpFunc*);
}


on ContextA, run testFunction(), console result is '*function*'

*Step3*:
In ContextB, call testFunction in ContextA
console result is '*undefined*',
and run tmpFunc(), report Exception '* is not a function*'


And For Object.create() 、Object.is() and so on shows OK. Only
StringToFunction shows error.
Do you know Why it causes such an issue? Any Advice ?


Pls,help.
Thank you for your time and I look forward to your reply.

-- 
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/CAP96edPrJ%2Bdm0dysQzFwiE7m_4En_ZhkYC60D8%2BtBaWCGU2_kg%40mail.gmail.com.

[blink-dev] Save the date for BlinkOn 16!

[Ashley Haman]

Bcc: blink-dev



TLDR: Save the date and join us on May 17-18, 2022 PST for BlinkOn 16!

Hi everyone,

We hope that you had a happy and safe holiday season! With the new year
upon us, we are planning for BlinkOn 16 in 1H 2022. Please find the details
below:


   -

   What: Combination of live and recorded sessions, including keynotes,
   lightning talks, breakout talks, and social events
   -

   When: May 17-18, 2022 PST
   -

   Where: Hybrid - while there are still a lot of unknowns, we are hopeful
   about the opportunity to connect with you in-person again, and we will keep
   you updated as we evaluate our options to safely host this event


Registration will open soon - please stay tuned for more details in the
coming weeks. Until then, if you have any questions or concerns, don't
hesitate to email us at blin...@chromium.org.

All the best,

BlinkOn Planning Committee

-- 
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/CANgQeaCkjk3Dm5nyhygVWbJ2pw7ep_K9h%2B%2BhmSDsPyqs54U%3DzQ%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Chris Harrelson]

This generally looks good to me, and probably safe to do. However, it'd
make me more confident if we could reduce the 0.3%. Is YouTube willing to
turn off their usage now? My guess is that will be most of the 0.3%. @Thomas
Steiner  is that doable?

On Thu, Jan 13, 2022 at 7:09 AM Raphael Kubo Da Costa <
raphael.kubo.da.co...@intel.com> wrote:

> *Contact emails *raphael.kubo.da.co...@intel.com, reil...@chromium.org
>
> *Explainer*
> None
>
> *Specification *https://w3c.github.io/battery
>
> *Summary *Deprecate and remove the Battery Status API on insecure
> origins, such as HTTP pages or HTTPS iframes embedded in HTTP pages.
>
> *Blink component *Blink>BatteryStatus
> 
>
> *Motivation *The Battery Status API allows web developers to have access
> to, among other things, a system's battery charging level and whether it is
> being charged. It is a powerful feature that has been around for over a
> decade and, as such, was originally designed with different security
> constraints.
>
>
> https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
> mentions how powerful features should not be exposed on insecure origins.
> We would like to add the [SecureContext] attribute to the spec's Web IDL
> so that navigator.getBattery() and the BatteryManager interface are only
> available in secure contexts.
>
> This has also been discussed in W3C at the Devices and Sensors WG April
> 2021 meeting, where we agreed to fix
> https://github.com/w3c/battery/issues/15 by adjusting the Blink
> implementation.
>
> Risks
> *Interoperability and Compatibility *Blink is the only engine
> implementing the Battery Status API, so most/all users are already expected
> to check for the presence of navigator.getBattery() before using it.
>
> We've been measuring usage of navigator.getBattery() in insecure contexts
> since M64. Per
> https://chromestatus.com/metrics/feature/timeline/popularity/2199 the
> counter sits at around 0.3% at the moment.
>
> However, none of the URLs listed there are using the Battery Status API
> directly. The largest occurrence is embedded YouTube videos: embedded HTTPS
> iframes on HTTP pages count as insecure contexts. Thomas Steiner reached
> out to the YouTube team internally and they said this change would not
> adversely impact them. Other usages of navigator.getBattery() in insecure
> origins come from trackers and RUM (real user monitoring) code added to the
> URLs listed in chromestatus.com. In all cases, feature detection is
> already done so existing code would not break. Gecko: N/A Gecko does not
> implement this API. WebKit: N/A Safari does not implement this API. Web
> developers: No signals
>
> Is this feature fully tested by web-platform-tests
> *?
> *Yes:
> https://wpt.fyi/results/battery-status?label=experimental&label=master&aligned
> (existing tests will be modified along with the Blink and spec changes)
>
> *Requires code in //chrome? *False
>
> *Tracking bug *
> https://bugs.chromium.org/p/chromium/issues/detail?id=1286748
>
> *Estimated milestones *Add a deprecation message in M100, stop exposing
> the Battery Status API to insecure origins in M103.
>
> *Link to entry on the Chrome Platform Status *
> https://chromestatus.com/feature/4878376799043584
>
> 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/3336a23c-7486-4312-a095-3928303c66e4n%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_0my8aprpJ_yY4baBDdDgHexwYBraGjDV4whUVgVtKQA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Propagate request origin and redirect chain in passthrough service workers.

[Ben Kelly]

Please re-test with canary 99.0.4827.0 or later.

For more information see:

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

On Wed, Jan 12, 2022 at 5:29 PM Rafael Santos Silva 
wrote:

>
> This change broke a SingleSignOn login on the FOSS software Discourse. We
> have a flow like:
>
> 1. User visits forum.siteA.com, click login
> 2. Gets redirected to idp.siteB.com
> 3. Fills login details
> 4. Gets redirected to forum.siteA.com/session/sso_login?parameters
> 5. Gets redirected to forum.siteA.com/homepage
>
> On step 4, the response includes a `set-cookie` header, with proper `HttpOnly;
> SameSite=Lax; Secure `and set. But if there is an active service worker,
> the login will fail as that cookie will be rejected by Chromium due to
> SameSite rules now.
>
> t=2971 [st=258]COOKIE_INCLUSION_STATUS
>--> domain = "forum.siteA.com"
>--> name = "_t"
>--> operation = "store"
>--> path = "/"
>--> status = "EXCLUDE_SAMESITE_LAX, DO_NOT_WARN"
>
> The service worker is a vanilla WorkboxJS service worker that intercepts
> all GETs with the "Network First" strategy.
>
> Disabling the service worker or using Firefox results in a successful
> login. There is no warning in either DevTools network tab nor the console
> that the cookie was rejected.
>
> Chrome 96: login works
> Chrome 97: login does not work
> Chrome 98: login does not work
>
> Is this expected behavior? Even if the request `GET forum.siteA.com` was
> initiated because of a redirect from a different domain, is it expected
> that Chrome will silently drop same site cookies from forum.siteA.com?
>
> Did not post this in the
> https://bugs.chromium.org/p/chromium/issues/detail?id=1241188 because
> it's not public.
> On Tuesday, November 30, 2021 at 5:27:47 PM UTC-3 wande...@chromium.org
> wrote:
>
>> On Tue, Nov 30, 2021 at 3:24 PM Joe Medley  wrote:
>>
>>> >Since the first part of the change is in M97 I updated the chromestatus
>>> entry to indicate that as the release and added a note that the
>>> redirect-chain change is coming in M98.
>>>
>>> Is any of this feature usable in 97?
>>>
>>
>> Yes.  Requests without a redirect will work in M97 and get the expected
>> origin header, sec-fetch-site header, and samesite cookies.  Some
>> restrictions redirected requests will only start being applied in M98.
>>
>>
>>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Nov 29, 2021 at 7:11 AM Ben Kelly  wrote:
>>>
 Thank you!

 FYI, I realized this morning I made one small mistake in my original
 post.  The origin propagation part of this intent is actually in M97 and
 the redirect chain part is in M98.  The CLs are large, so I don't really
 want to do a merge if I can avoid it.  Since the first part of the change
 is in M97 I updated the chromestatus entry to indicate that as the release
 and added a note that the redirect-chain change is coming in M98.  Sorry
 for the confusion here.

 Please let me know if there is any concern about this clarification.
 Thanks.

 On Thu, Nov 25, 2021 at 1:21 AM Mike West  wrote:

> LGTM3.
>
> On Wed 24. Nov 2021 at 23:59 Rick Byers  wrote:
>
>> Makes sense, thanks! Arguably almost a bugfix level change. LGTM2
>>
>> On Wed, Nov 24, 2021 at 5:27 PM Ben Kelly 
>> wrote:
>>
>>>
>>>
>>> On Wed, Nov 24, 2021, 5:07 PM Rick Byers 
>>> wrote:
>>>
 Ben, can you speak to the web compat implications (or absence
 thereof) to this change in behavior?

>>>
>>> I believe the compat risk should be minimal.  This change only
>>> matters for navigation requests and many service workers will be using 
>>> nav
>>> preload instead of calling fetch() themselves.
>>>
>>> For sites not using nav preload it's possible they will see changes
>>> in origin headers, sec-fetch-site headers, and SameSite=Strict cookies.
>>> Depending on server logic that could cause requests to be deemed unsafe 
>>> by
>>> the server and fail.  However, it would match what is done without a
>>> service worker present.  Arguably the server wants to make this 
>>> decision in
>>> these situations.
>>>
>>> If a site does not want this behavior it requires only a small
>>> service worker change to get previous behavior.  They just need to fetch
>>> the url and not the full request.  Like `fetch(evt.request.url)` 
>>> instead of
>>> `fetch(evt.request)`.
>>>
>>>  Nov 24, 2021 at 5:03 PM Chris Harrelson 
 wrote:

> LGTM1
>
> On Wed, Nov 24, 2021 at 1:52 PM Ben Kelly 
> wrote:
>
>> On Wed, Nov 24, 2021 at 4:40 PM Ben Kelly 
>> 

[blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Raphael Kubo Da Costa]

*Contact emails *raphael.kubo.da.co...@intel.com, reil...@chromium.org

*Explainer*
None

*Specification *https://w3c.github.io/battery

*Summary *Deprecate and remove the Battery Status API on insecure origins, 
such as HTTP pages or HTTPS iframes embedded in HTTP pages.

*Blink component *Blink>BatteryStatus 
BatteryStatus>

*Motivation *The Battery Status API allows web developers to have access 
to, among other things, a system's battery charging level and whether it is 
being charged. It is a powerful feature that has been around for over a 
decade and, as such, was originally designed with different security 
constraints.

https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
 
mentions how powerful features should not be exposed on insecure origins. 
We would like to add the [SecureContext] attribute to the spec's Web IDL so 
that navigator.getBattery() and the BatteryManager interface are only 
available in secure contexts.

This has also been discussed in W3C at the Devices and Sensors WG April 
2021 meeting, where we agreed to fix 
https://github.com/w3c/battery/issues/15 by adjusting the Blink 
implementation.

Risks
*Interoperability and Compatibility *Blink is the only engine implementing 
the Battery Status API, so most/all users are already expected to check for 
the presence of navigator.getBattery() before using it.

We've been measuring usage of navigator.getBattery() in insecure contexts 
since M64. Per 
https://chromestatus.com/metrics/feature/timeline/popularity/2199 the 
counter sits at around 0.3% at the moment.

However, none of the URLs listed there are using the Battery Status API 
directly. The largest occurrence is embedded YouTube videos: embedded HTTPS 
iframes on HTTP pages count as insecure contexts. Thomas Steiner reached 
out to the YouTube team internally and they said this change would not 
adversely impact them. Other usages of navigator.getBattery() in insecure 
origins come from trackers and RUM (real user monitoring) code added to the 
URLs listed in chromestatus.com. In all cases, feature detection is already 
done so existing code would not break. Gecko: N/A Gecko does not implement 
this API. WebKit: N/A Safari does not implement this API. Web developers: 
No signals

Is this feature fully tested by web-platform-tests 
*?
 
*Yes: 
https://wpt.fyi/results/battery-status?label=experimental&label=master&aligned 
(existing tests will be modified along with the Blink and spec changes)

*Requires code in //chrome? *False

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

*Estimated milestones *Add a deprecation message in M100, stop exposing the 
Battery Status API to insecure origins in M103.

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

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/3336a23c-7486-4312-a095-3928303c66e4n%40chromium.org.

Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

[Yoav Weiss]

On Wed, Jan 12, 2022 at 8:33 PM Anupam Snigdha  wrote:

> Hi Philip,
>
>
>
> In the worst case we will be able to merge the pickling API changes
>  into the EditingWG repo.
> We have a meeting this Friday with the Firefox folks to discuss the
> Pickling API as they were also interested in the proposal
> .
> If we have consensus there, then we will be able to add pickling API to the
> official clipboard spec.
>
> Overall I think the algorithms required to implement Pickling API
> 
> is included in the forked PR. There are few concerns regarding
> sanitization, but we couldn’t come to an agreement with Apple folks
> 
> to standardize it.
>

Regardless of venue and consensus, it seems important that you'd have a
spec that clearly outlines what you are trying to ship here, so that if and
when other vendors would like to follow (e.g. you mentioned Firefox are
interested in following) they would be able to.

Moreover all browsers have different sanitization behavior in the clipboard
> copy/paste methods so it will be hard to change anything there without
> breaking the legacy DataTransfer APIs that use the same sanitization
> algorithms.
>
>
>
> Thanks,
>
> Anupam
>
>
>
> *From:* Philip Jägenstedt 
> *Sent:* Wednesday, January 12, 2022 8:42 AM
> *To:* Anupam Snigdha 
> *Cc:* Domenic Denicola ; Chris Harrelson <
> chris...@chromium.org>; Daniel Bratell ; Yoav Weiss <
> yoavwe...@chromium.org>; blink-dev ; Alex Russell
> ; Abhishek Rathi ;
> svo...@gmail.com ; ajayra...@google.com <
> ajayrahate...@google.com>; Bo Cupp ; m...@google.com
> ; Joshua Bell ; Victor Costan <
> pwn...@chromium.org>; Scott Low 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling
> for Async Clipboard API
>
>
>
> Hi Anupam,
>
>
>
> Could https://w3c.github.io/gamepad/extensions.html
> 
> be a model to follow here? I think it's important to write down (and test)
> what you intend to ship in something that looks like a spec. If doing that
> in the EditingWG doesn't seem tractable, then the WICG is also an option.
>
>
>
> This seems like a fairly frustrating situation, but I hope it's clear what
> to try next. If you do feel like you're stuck with what to do with the
> spec, feel free to ask for advice here or off list.
>
>
>
> Best regards,
>
> Philip
>
>
>
> On Thu, Jan 6, 2022 at 8:16 PM Anupam Snigdha 
> wrote:
>
> Re: “but I guess it did not actually include the pickling parts yet!”: It
> does include the pickling parts. See the unsanitized option in the
> ClipboardItemOptions dictionary, write unsanitized format, os specific
> custom map name and os specific custom name sections in the PR for more
> details.
>
>
>
> The part that is missing is the one that you mentioned “what to do for
> non-text data types being written to the clipboard. (Ctrl+F for "This is
> left to the implementation..." in
> https://github.com/w3c/editing/pull/383/files
> 
> .) ”
>
>
>
> “I think it's still important to write a spec somewhere, even if the
> EditingWG does not host it” – We will be merging this into the Editing
> repo, but it wouldn’t be part of the official clipboard API spec due to
> disagreement with Apple. Looks like FF is also interested
> 
> in standardizing the sanitization behavior because the legacy DataTransfer
> APIs behave the same in Chromium, FF, old Edge and IE, but since Apple
> opposed to these changes we couldn’t include it in the official clipboard
> API