On 12/16/21 5:52 PM, Charlie Reis wrote:
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 <http://www.host.com>, site-keyed agent cluster (current default) document.domain = "host.com <http://host.com>" // Succeeds. document.domain; // returns "host.com <http://host.com>". // On a domain www.host.com <http://www.host.com>, origin-keyed agent cluster (future default) document.domain = "host.com <http://host.com>" // Doesn't throw. Doesn't do anything else either. document.domain; // Still returns www.host.com <http://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 onhttps://deprecate.it/#document-domain <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 <http://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.)
Yeah, I hear you - the unpredictability is a challenge. My preferred approach would be to hold things at 100% in pre-release channels for some period of time to sniff out compat bugs - but AIUI, this isn't really a thing that Finch is designed to do, and pre-release comes with its own set of biases that may not accurately reflect release behavior. But where the risk is non-zero, only breaking some users seems better than breaking all users, even if imperfect.
-- 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/403f2615-fcdc-2240-0653-94c32a684874%40chromium.org.
