Thanks for the detailed report!! It's great that we've managed to bring the usage down, but 0.25% is still too high for my comfort levels. Taking a manual survey of the major users seems like the right approach. I wonder if you could, on top of the top sites, also run a random survey of the bottom half of usage, to get a sense of breakage there?
On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim <vogelh...@google.com> wrote: > Hello all, > > It's been a while and 109 is coming up. As I'm preparing the > intent-to-ship for 109, I'd like to post an update on how the deprecation > is going: > > Current usage: Since announcing the deprecation, usage of > document.domain-enabled accesses have dropped by about 50%. > > - Feature stats: DocumentDomainEnabledCrossOriginAccess > <https://chromestatus.com/metrics/feature/timeline/popularity/2544> > > - Note that this *includes* usage when an Origin-Agent-Cluster header is > explicitly set, which is sustainable use that is not affected by the > deprecation. > > - CrossOriginAccessBasedOnDocumentDomain > <https://chromestatus.com/metrics/feature/timeline/popularity/4171> is > usage of document.domain enabled access, but only when based on the > Origin-Agent-Cluster's default (which is what this intent wants to change.) > This graph has the correct numbers for this intent; but makes long-term > trends harder to see because we only introduced the use counter *during* > the deprecation period. > > - So basically, usage has dropped form ~0.5% of page views ( > DocumentDomainEnabledCrossOriginAccess > <https://chromestatus.com/metrics/feature/timeline/popularity/2544> @ Nov > '21) to about ~0.25% of page views (CrossOriginAccessBasedOnDocumentDomain > <https://chromestatus.com/metrics/feature/timeline/popularity/4171> @ > Sept '22) > > When gathering the data for this post, I double-checked on a particular, > well-known media site that we had contacted about the deprecation during > the past months. I was surprised to notice that despite our outreach and > communication, they *still* use document.domain and document.domain > facilitated cross-origin access. But when taking a closer look, an > interesting find emerged: They are using document.domain setting to enable > auto-play of their media player, which is hosted on a separate domain. Our > advice was to use the 'autoplay' permission policy with permission > delegation instead. They are indeed doing so, but *in addition* to > document.domain setting. In other words, they opted for a conservative > implementation strategy where they auto-play their frame with two different > methods. When I load their page with document.domain setting disabled, it > works fine. That's a fine implementation strategy, but unfortunately it > mucks up our statistics since our use counters cannot know whether other > code exists to compensate for a failed document.domain facilitated access. > > When discussing this finding with another engineer, he suggested that > we're really interested in user-visible web breakage. Since I don't know > how to measure that directly, I manually looked at all top users of > document.domain and loaded each page with/without document.domain setting > to see if I could spot any difference. Document.domain usage - like the web > in general - is quite "top heavy": 9 sites account for about 50% of all > remaining dd usage. > > - 7 sites work without any discernible difference. (Caveat: Many use > languages I do not understand, which makes it difficult to spot subtle > differences in content. But to me, the sites looked and used the same, > regardless of document.domain setting. Caveat 2: One site requires a login, > so I could only really test the login page rather than their core > functionality.) > > - 1 site worked just the same, except for a pair of very extra fancy ad > frames that "framed" the main content left and right. The main content, > including in-page ads, seemed just fine, but the fancy ad frames were > missing. > > - 1 site was clearly missing content. > > For both of the last two, the console showed uncaught DOM exceptions for a > failed cross-domain access. What I suspect happens in the first case is > that during construction of the fancy ad frames an exception is thrown and > hence the frames aren't inserted in the page. In the second case something > similar happens, but when building up the main content. Or maybe before > building up the main content. Thus, that part of the main content is > missing. > > (We don't like broken web pages, so we reached out separately to the > owners of that last page on Friday. Their support has promised to put us in > contact with one of their developers which, as of this writing, hasn't > happened yet.) > > > On Fri, Jan 21, 2022 at 9:23 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> LGTM1 to deprecate under the following conditions: >> >> - As discussed, a 6 months deprecation period, as well as broad-scope >> and targeted outreach, that would hopefully bring usage down. >> - A well-crafted deprecation message that indicates the timeline, and >> at the same time indicates that we'll be responsive to community feedback >> (or a link to a blog post/documentation page that indicates the same) >> - Sending a separate intent for the actual removal at the end of the >> deprecation period, once the picture is a bit clearer. >> >> -- 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/CAL5BFfUp0Ltr7S52nSNq4--E1uA2-pwZ4qDA2OYoV31VR92HPw%40mail.gmail.com.
