To simplify and keep this moving, I've filed https://github.com/mozilla/standards-positions/issues/759 as an umbrella issue for anything URL in Interop 2023.
My view is that we can't improve our risk assessment of this by much with metrics, because we can't distinguish between harmless and serious breakage. Instead what we should do is take some comfort in the fact that the behavior is already shipping in Safari, try to ship it and revert at the first sign of trouble to evaluate. In other words, I'll happily LGTM this, but I'll send this round of feedback first, in case Yoav disagrees with that. Some additional replies inline: On Mon, Mar 13, 2023 at 5:30 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > Thanks for working on interop! :) > Indeed, I'm very grateful and happy to see this work! Can you please explain what would be the impact of this change and provide > examples of cases that are currently working and would stop working after > this change is landed? > Web developers are asking questions on this thread, and it'd be good to > have an explainer that answers such questions. > I've replied to Eli. More generally, since this is a change in the nitty gritty details, my concrete advice for web developers would be to test what Safari currently does and assume that's what Chrome is going to start doing. If one doesn't have access to Safari, then https://www.browserstack.com/screenshots can be used for one-off tests, as long as the test result appears on the page. The other difference to Safari that's easy to test for is when exceptions are thrown. `new URL('https://example|.com')` returns a URL escaped as " https://example%7C.com"; in Chrome, but throws TypeError in Safari. Do we have use counters for content that would start throwing once this > change lands? > I'll let Jiacheng answer, but if the answer is no, I'm skeptical that adding use counters will meaningfully help us judge the risk of this. Breaking it down: - Many invalid URLs already throw exceptions, which may be caught. Knowing that new exceptions will be thrown in X% of page views will not help know how often those are caught and the web app still behaves correctly. - Changes in serialization are akin to changing a return value. We can't instrument the downstream effects of that and determine if the difference led to a different outcome. Can you provide a link to the tests? > https://wpt.fyi/results/url?label=experimental&label=master&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2023-url There's no way to link to exactly the subtests that will be affected, but "Parsing: <http://example example.com> against <http://other.com/>" in url-constructor.any.html is one of them. Best regards, Philip -- 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/CAARdPYdKrtMS10VJxvzKntoXMBOEaA1doTYqpQ1W4%2BX1q40-bg%40mail.gmail.com.
