This isn’t “IE forced Mozilla to freeze” anything. It’s super important you understand: any site specific UA issues are site bugs and lazy webdevs, not any of the browser engineers faults.
Otherwise I could say “remember when Netscape forced safari 2.0.4 to change its UA string”, rather than “remember when shitty sites detected support for jss/layers by looking for 4 in the UA string”
Isn’t it a problem of the ecosystem and not “lazy devs”. The web dev side of things has to build detection on top of an unstructured string that kept accreting parts and when a new complications arose the browser dev community had to append more parts or make weird additions which results in the web dev community doing more weird parsing and rule selection.
The web devs and the browser devs can’t strictly coordinate because a change made in the browser now is not fully available for weeks/months/years (depending on the users of interest). So the remaining solution is to share more unstructured info in the user-agent string while trying the best for compatibility on both sides.
We’ve had more than a decade now of telling devs not to queue behaviour on the UA, On top of that even non-browser dev sites have also been saying: do not configure behaviour on the UA string.
Any site written in the last decade that blocks based on arbitrary substring checks on the UA is a bad site, and the developer responsible for it is lazy, and should feel bad. WebKit, Blink, and Gecko are largely compatible and any variation in behavior is testable, and simply blocking entire browsers indicates at best laziness. There’s a tendency of webdevs at the moment to say “if it works in chrome my site is correct”, which is exactly what this same caliber of developer did in the pre-chrome era with their IE only BS.
This isn’t “IE forced Mozilla to freeze” anything. It’s super important you understand: any site specific UA issues are site bugs and lazy webdevs, not any of the browser engineers faults.
Otherwise I could say “remember when Netscape forced safari 2.0.4 to change its UA string”, rather than “remember when shitty sites detected support for jss/layers by looking for 4 in the UA string”
Isn’t it a problem of the ecosystem and not “lazy devs”. The web dev side of things has to build detection on top of an unstructured string that kept accreting parts and when a new complications arose the browser dev community had to append more parts or make weird additions which results in the web dev community doing more weird parsing and rule selection.
The web devs and the browser devs can’t strictly coordinate because a change made in the browser now is not fully available for weeks/months/years (depending on the users of interest). So the remaining solution is to share more unstructured info in the user-agent string while trying the best for compatibility on both sides.
We’ve had more than a decade now of telling devs not to queue behaviour on the UA, On top of that even non-browser dev sites have also been saying: do not configure behaviour on the UA string.
Any site written in the last decade that blocks based on arbitrary substring checks on the UA is a bad site, and the developer responsible for it is lazy, and should feel bad. WebKit, Blink, and Gecko are largely compatible and any variation in behavior is testable, and simply blocking entire browsers indicates at best laziness. There’s a tendency of webdevs at the moment to say “if it works in chrome my site is correct”, which is exactly what this same caliber of developer did in the pre-chrome era with their IE only BS.
I wonder if the version numbers above 120+ will un-freeze that part of the User-Agent.
I guess this as good a moment as any to just freeze this string completely, forever.
Abandon or transform into something structured and machine-readable: https://user-agent.globalcode.info/ + https://lobste.rs/s/e5xytk/user_agent_uri
Well, if Mozilla introduces a bug in version 112, it’s nice to be able to work around that for users running that version.
Or wait six weeks for the next Firefox release to auto-upgrade itself without user consent.
Not a good option, but the one Mozilla seems to be banking on.
Some browser bugs stay for years or even decades.
For example,
<select>with<datalist>still doesn’t work properly on Firefox for Android.I am aware. XD
That’s essentially what is happening: that’s why safari on arm reports itself as intel.