On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev < [email protected]> wrote:
> 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. > In my experience (caveat: I'm not an API owner), it's harder to repro and triage compatibility bugs that get filed if a feature is only enabled for a percentage of users via Finch. It tends to be quicker to bisect reports and get attention on a compat bug if the feature is enabled on trunk instead, with an easy way to revert if needed. (Finch is certainly better when you care about performance issues, which doesn't seem to be the case here.) Charlie > -- > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOOVfCH42eaBeoGCn6KCKjOvoJa1ZY4wY8%3DXHooVytAiA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAH%2B8MBatS6T1AOVdZ2JJMJeu5j_LRkAf4MSejZnMW%3DXaE--yyw%40mail.gmail.com.
