3 ms·
If I'm reading the issue thread correctly, it seems that a big revision of the hit testing code was being field trialled (ie enabled for 1% of stable users) and
by sgentle 7y ago
If I'm reading the issue thread correctly, it seems that a big revision of the hit testing code was being field trialled (ie enabled for 1% of stable users) and a fix to that code in Chrome 77 caused a bug for the other 99%. Unfortunately, this new bug was only discovered partway through version 77's rollout.
So now there's a bit of a pinch: revert the fix (and break it for the 1%), or leave it (break it for the 99%). Presumably, you could disable the field trial AND revert the fix at the same time, but that wasn't considered. I'm not sure why, but my guess would be that it's a pain in the butt to coordinate both rollout systems.
Obviously the right answer is to make a new fix that doesn't break things for any users, but fixes take time and the release was already halfway rolled out. I think that's where the discussion about impact came from, and the initial assessment was that it wouldn't break much stuff, so the fix was bumped to the next release (Chrome 78).
However, after lots of people jumped on the issue tracker to say it did, in fact, break a bunch of stuff, Chrome 77 was re-released ("respun") with the new fix included.
So, broadly speaking, I think the decisions here made sense under the assumption that it was a small-impact issue. My main criticism would be that there must be a more effective way to estimate impact than waiting for people to complain in the bug tracker.
One approach would be some kind of reverse integration testing system. ie, if you have a critical app or library that depends on Chrome, there should be some way of submitting your tests so that the Chrome team can estimate the impact of changes and find out more easily if they'll break anything unexpected.
Rust does this with a system called Crater: https://rust-lang.github.io/rustc-guide/tests/intro.html#crater https://rust-lang.github.io/rustc-guide/tests/intro.html#cra...
And apparently Yocto has something similar: https://lwn.net/Articles/788626/ https://lwn.net/Articles/788626/
- ninju 7y ago>...My main criticism would be that there must be a more effective way to estimate impact than waiting for people to complain in the bug tracker. This is very true. There are 100s if not thousands of people for every support person that knows about new Chrome updates and Bug Tracker for opening issues. Users are told to trust Chrome updates and assume that updates won't affect existing functionality and so the idea of opening a browser support ticket does immediately come to mind.