On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor <[email protected]> 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.

> Current usage of the document.domain: 0.05%
> <https://chromestatus.com/metrics/feature/timeline/popularity/2544> of
> page views rely upon document.domain to enable some cross-origin access
> that wasn't otherwise possible. 0.24%
> <https://chromestatus.com/metrics/feature/timeline/popularity/2543> of
> page views block same-origin access because only one side sets
> document.domain. Both counters can be found on
> https://deprecate.it/#document-domain, too.
>
> (cool site, btw)
>
> We’ve reached out in advance to 4 of the top current users - TL;DR Most of
> their use cases could be achieved already by different APIs e.g.
> Audio/video autoplay in iframes by adding the ‘autoplay’ attribute, support
> chat deployed across subdomains.
>
> Out of curiosity, did any of them mention what couldn't be achieved via
> existing APIs?
>

I checked back, and nothing particular came up. It seems that migrating off
of document.domain isn't blocked by a lack of options.

Activation - Deprecation plan
> M98 - Add the devtools issue and warning incl. a web.dev blog post to
> guide adoption
>
> * M98-M100 - Monitor use counters and reach out to current users *
>
> What's the plan if the use counters don't move? Do you have a minimum page
> view % in mind you would want before proceeding to the next step (even if
> it meant delaying the timeline)?
>

We don't have a dead-set plan. The primary idea is a combination of
delay-ing until usage is low enough, and outreach to offending sites to
educate about the problem & available alternatives.



> * M101 - Deprecate the feature by default. No reverse-origin trial is
> planned as the ‘Origin-Agent-Cluster’ http header can be used to gain
> access to the feature. *
>
> Would this disabled-by-default change ride the trains, or have you
> considered finching it out to assess compat risk?
>

My original plan was to enable it by default in the 101 release, and have a
Finch switch as an emergency-off. Reading the feedback here, maybe it's
better to incrementally enable it via Finch. I'll be happy to follow
whatever path API owners prefer.

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOOVfCH42eaBeoGCn6KCKjOvoJa1ZY4wY8%3DXHooVytAiA%40mail.gmail.com.

Reply via email to