Fun fact, we recently found a performance issue on one of our products which I was completely unaware of because it didn't affect. Even now, we cannot get Chrome to match FF's performance especially (of all things) for Google maps. Just goes to show that basic assumptions that Chrome is faster than Firefox are not 100% accurate. Like most things, it depends.
It's kind of an aside, but is that true? I only do small scale solo dev but I test in like a dozen UA as the bare minimum I can get away with.
Presumably you're being slightly hyperbolic and saying that devs who are under major constraints will target Chrome?
> In addition, it removes the old properties which were part of the earlier Scroll Snap Points Specification.
The earlier API was based on a working draft spec and has been available since 2015 in Firefox (Chrome only brought it out without a flag in 2018), so this isn't a recent development.
> The update in Firefox 68 brings the Firefox implementation in line with Scroll Snap as implemented in Chrome and Safari
While "and Safari" is a less-relevant detail here, the general point is: where there is a monopoly, minority browsers will often need to implement user-hostile features in order to remain relevant/up-to-date/compatible.
Web devs today don't test in Firefox, they test in Chrome. They might have a webdriver/saucelabs/etc. setup with Firefox/IE/Edge thrown in but in terms of day-to-day these are afterthoughts.