Mike, do you mean in order to put this behind Finch? On Mon, Mar 13, 2023 at 3:06 PM Mike Taylor <miketa...@chromium.org> wrote:
> Yes, ideally this change ships behind a flag. > On 3/13/23 7:43 AM, 'Jiacheng Guo' via blink-dev wrote: > > For Eli Grey's question: > Yes, the behavior will change with the feature. > > I believe it's reasonable to add use. The isValidHost function behavior > varies among different browsers. The change will make Chrome act as the URL > standard. > > I believe it's reasonable to add a use counter for the feature. Since the > CL is created by an external developer, would you suggest creating a > feature flag for it as well? > > Jiacheng Guo > > On Mon, Mar 13, 2023 at 7:31 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> >> >> On Mon, Mar 13, 2023 at 11:21 AM Philip Jägenstedt <foo...@chromium.org> >> wrote: >> >>> On Mon, Mar 13, 2023 at 11:05 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Mon, Mar 13, 2023 at 10:46 AM Philip Jägenstedt <foo...@chromium.org> >>>> wrote: >>>> >>>>> 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. >>>>> >>>> >>>> Metrics can give us an upper bound, as well as a pile of examples that >>>> one can then manually sample and assess 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. >>>>> >>>> >>>> Those are not contradictory. E.g. we could add metrics (+UKM) and a >>>> flag, and then be alert for bug reports from Beta, as well as randomly >>>> examine sites that touch the relevant usecounters and see if they were >>>> broken. >>>> Would that work from your perspective? >>>> >>> >>> Is the suggestion to do the same as in >>> https://chromium-review.googlesource.com/c/chromium/src/+/4252309 (for >>> Intent >>> to Ship: Port overflow check in URL setters >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/xsITedSTDnM/m/ANFrwCN0BgAJ>) >>> to add the use counter but not wait for data before trying to ship this? >>> >> >> That's what I'm suggesting (+ a manual sampling & inspection of URLs we'd >> get from UKM to actively verify there's no significant breakage coming) >> >>> >>> That would work for me if Jiacheng thinks it's reasonable in this case. >>> >> -- > 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/CAJQw1NywiOk%2BFqtS4-nPDSjbp%3DBFfQ9wtENFVw7ue7EX8yim5g%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NywiOk%2BFqtS4-nPDSjbp%3DBFfQ9wtENFVw7ue7EX8yim5g%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdAFPRb0Cv8CLHkZ6-6FEtxKGnNFD8OL%2B%2B2s0K2-B6x8Q%40mail.gmail.com.
