I have made public copies of the sheets and proposed updates in the doc. Also linked below.
Steinar and I analyzed about half of the sites each, so I can say something about the findings. html2image: - https://docs.google.com/spreadsheets/d/1w2RuTpw3KG5zFvk9dmRlK-cS38MydyErnsUJzJ12AW8/edit?usp=sharing - Found by looking for the string "html2image", which appears in an attribute name ("data-html2canvas-ignore") used by the library - This is a 1% random sample of the results (the total was around 250k) html-to-image: - https://docs.google.com/spreadsheets/d/1uV-8cWpLOMfIpo0JnpBpaDmWKznzFe4nqpkOmUyhWGc/edit?usp=sharing (100% of the results) - Found by looking for the combination of strings "Error inlining remote css file" AND "includeQueryParams" (found by iterating on broader queries with many false positives) - These are all of the results For both libraries, the most common finding by far was that the libraries are loaded, usually as part of a minified bundle, but that we couldn't find any piece of UI on the site that would invoke it. For some sites you could see a plausible usage, but it was behind a login or some kind of checkout flow that we didn't proceed through. For example, a food delivery service might generate a PDF receipt at the end. We spent at least 5 minutes per site testing, sometimes more. Despite our best efforts in devtools we couldn't find a way to trigger it on any of the sites (30 in total) randomly picked. I also went to look at a few Swedish sites where I could understand the meaning of everything, and still failed. *Conclusion*: Of the sites that embed these libraries, a vast majority either don't actually use them or it's a few steps into some process or behind a login where we cannot reach it. It might still be important, but not to drive-by visitors at least. Given this, we think that the best approach is to carefully roll this out with Finch and monitor guardrail metrics to ensure no measurable regression. We've provided workarounds for the main libraries we've found ( here <https://github.com/niklasvh/html2canvas/pull/3252> and here <https://github.com/bubkoo/html-to-image/issues/542#issuecomment-3249408793>) and think the fact that Firefox and Safari already ship this behavior is reason to think the problem is small. On Thu, Sep 4, 2025 at 5:36 PM Yoav Weiss (@Shopify) <[email protected]> wrote: > > > On Thu, Sep 4, 2025 at 3:52 PM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> >> >> On Thursday, September 4, 2025 at 2:47:24 PM UTC+2 Steinar H Gunderson >> wrote: >> >> On Thu, Sep 04, 2025 at 02:34:08PM +0200, Yoav Weiss (@Shopify) wrote: >> > Thanks for the description of the issue! >> > Is there any way to estimate how many sites will be impacted by the >> > slowness here? Do we have a use counter of some sorts? For ones that >> are >> > impacted, how much slower do they become? Are they still usable? >> >> Yes and no. We want to roll this out via Finch, which will at least give >> us >> confidence that it won't have large-scale problems across the web. As for >> individual sites, it really depends on a lot of factors; in particular, >> how big are the DOMs, how many custom properties does each element have, >> how patient is the user? For most cases, the difference is basically >> zero. >> If you have 2000+ custom properties on each element (something that we >> don't >> recommend, but some extreme sites do it nevertheless), you are talking >> going >> from 15 seconds to several minutes. >> >> >> That sounds equivalent to "completely broken". >> >> >> It is still usable, but the user will >> probably eventually tire of waiting if the long is long enough. >> >> It is challenging to make an accurate use counter for this. We could have >> a >> counter like “you are accessing custom properties on gCS and you have >> more >> than 500 of them”, but it would have large amounts of false positives. >> For instance, this isn't a problem if you also have a small DOM. It's not >> a >> problem if you see them and immediately skip over them instead of cloning >> them onto the new element (the recommended patches to html2canvas and >> html-to-image do this). Similarly, I suppose “you are using setProperty >> to >> set more than 500 properties on an element” is going to be very >> imprecise. >> >> This is why we've been using HTTP Archive to try to quantify the impact >> manually, however imprecise. >> >> > Looking for that data in your doc, I found a couple of non-public Sheets. > Would you be able to summarize your findings from that investigation? It > may help us quantify the impact. > > >> And that tells us that while it's common to >> include these libraries, actually hitting them in normal use is not that >> common, at least in our normal as-a-user experience. >> >> >> I can definitely sympathize with the challenge. But as is, you're >> essentially telling the API owners that an unknown amount of websites will >> stop working without warning, and without recourse other than their >> developers (if any) actively coding their site to use a different library. >> IMO, that's a hard sell without more data that would help us better >> quantify the damage. >> >> >> >> > Would we have some way of pointing the developers of such sites to >> snapDOM >> > or other solutions? >> >> None beyond the bug reports; we've engaged both on the Chromium bug >> report we >> received as well as bug reports in the relevant upstream libraries >> (including >> pdf.js, which is popular and uses html2canvas), and our experience is >> that >> developers have few problems adjusting as long as they know what the fix >> is. >> >> Of course, they've already had to contend with this slowness for Firefox >> and >> Safari users; >> >> > Have you reached out to Gecko/WebKit compat teams? > They may have insights on the magnitude here. > > >> some of them may not care, though. But fixing it for M141 >> will also fix it for users of those browsers. >> >> /* Steinar */ >> -- >> Homepage: https://www.sesse.net/ >> >> -- 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYf6skSfxrViu%2B4-YFC%2BTxySVTgF8ZdUXat_W95TUpaBLw%40mail.gmail.com.
