Stack Exchange changes broke UI on multiple legacy browsers - Again

Question

The previously reported and resolved issues of broken UI behaviour on legacy browsers (Latest Stack Exchange changes broke UI on Firefox Android), specifically, Firefox 68.11.0 (the last one before the brutal browser UI revamp) have returned. Also related report: Was support for the SeaMonkey browser just removed?

At some point in the last ~12-14 hours, I noticed the "Add a comment", the hamburger menu, Inbox, Achievement and Stack symbol (communities selector) drop-down expansions, up/down vote, bookmark, all stopped working again.

I raise this as a new issue since the original reports were against the mobile UI and have been presented with the common UI for some time now. I don't see any listed changes as having occurred in the time-frame in question in this answer, so sincerely hope it was an erroneous change.

I appreciate there was a lot of back and forth on the previous issues regarding backward compatibility for "unsupported browsers" but it was resolved once before. I'd ask the responses not go down the, "Just upgrade your browser or switch browsers path". It it wasn't broke, why break it? Yes, I accept the security risks of using an unsupported browser, just as I do driving an out of warranty car.

I put the question out again, if changes applied in the last day could be reviews and the once previously restored compatibility fix reapplied.

Additional observation: If clicking on the Inbox or Reputation icon, you end up on a page: https://stackexchange.com/users/<number>/<name>?tab=inbox, the equivalent of clicking on the "Inbox | all items", which displays as a classic full page (like "Request Desktop Site", not fitted to the mobile display size (i.e.: tiny text, etc.). On that page, the drop-downs all still work as expected. Weird.

Also reported as broken are Silk browser (Amazon platform) and Waterfox Classic and MyPal (used on legacy OS - Win 7 /XP). Not everyone can afford a new PC just to get to S/E and if your device provider or OS doesn't let you install any old (i.e.: new browser), are you simply out of luck?

Answer 1

Looks like it may have been caused by an optional chaining operator in some JavaScript once again. I'm seeing the following error in my error console for Meta:

Timestamp: 3/1/2022, 3:09:41 AM
Error: SyntaxError: expected expression, got '.'
Source File: https://meta.stackexchange.com/Content/Js/full.en.js?v=cffdde623a86
Line: 1, Column: 72811
Source Code:
arams.delete("page"),n.searchParams.delete("tab");const s=n?.toString().replace(/#.*$/,"");window.location.href=s+"#tab-

And for Stack Overflow:

Timestamp: 3/1/2022, 3:12:29 AM
Error: SyntaxError: expected expression, got '.'
Source File: https://cdn.sstatic.net/Js/full.en.js?v=cffdde623a86
Line: 1, Column: 72811
Source Code:
arams.delete("page"),n.searchParams.delete("tab");const s=n?.toString().replace(/#.*$/,"");window.location.href=s+"#tab-

Also, when I begin to answer, I see the following error, which may be unrelated:

Timestamp: 3/1/2022, 3:12:40 AM
Error: XML Parsing Error: no root element found
Location: https://stackoverflow.com/accounts/email-settings-form?_=1646122348703
Line Number 1, Column 1:
Source File: https://stackoverflow.com/accounts/email-settings-form?_=1646122348703
Line: 1

Answer 2

This is now fixed. Thanks for highlighting the specific optional chaining usage here. Because this was an isolated instance where it was easy to rewrite the logic to not use optional chaining, I was able to get the fix in.

Please understand though, we cannot guarantee that all issues related to maintaining compatibility for older browsers will be addressed in the future. I am quite certain that at some point we will run into issues like this where the cost required for accommodating the capabilities of old unsupported browsers will be a bit too high. Until then, happy to evaluate these as they come up.

As a side note: our JavaScript migration project should actually make this easier to handle (at least up to a certain point), since we are taking the opportunity afforded by the project to convert many of our legacy JavaScript files to TypeScript (and TypeScript itself can allow us to transpile code to earlier script compatibility versions while allowing us to use many of the newer language features). This doesn't change my certainty mentioned in the previous paragraph that we will not be able to accomodate the features of older browsers indefinitely. But it is something that may help to delay it in some cases.

optional chaining
support from major browsers
for quite some time now

Answer 3

There's an interesting question - What's a reasonable point not to support old browsers. Its not a matter of bandaiding the current breakages, but to actually try to figure out what's a reasonable feature set to support.

I've always been under the impression the last 2 versions 'rule' was very much so SE didn't need to test every single feature of their sites across multiple versions and platforms.

I've tried to run the modern net on OS/2 Warp years ago as part of a Super User answer years ago, partially as a joke. I do realise not everyone can run the latest and greatest OS (though, I was briefly running some machines that went from XP -> 7 -> 10). There's going to be a point of hard breakage, or being unable to move forward/ Likewise with less common systems - net positive on haiku dosen't run SE and that would mean I could run most of my day to day stuff on that platform if I chose. (It runs well on older hardware, and seems like a fun idea). Some of these platforms are going to reach the same status as a niche system, or are balanced on the edge of being retro-tech.

XP had support dropped over a decade ago, Windows 7 2 years ago. Not even counting the rapid development of modern browsers, and the effective browser duopoly - at some point supporting absolutely ancient browsers or their semi-orphaned descendants isn't going to be a productive use of time.

A common thread here is many of the browsers are "hobbyist" forks - running older engines (gecko/goanna for example), which may not be keeping up with more modern features. The main goal is running on older PC mostly usably. I do understand the desire to keep gear and systems that work as long as possible, and for freedom of choice of OSes and browsers but keeping them tested and working feels like a bit of an additional burden. There's also a matter of, even if the browsers are getting security updates, how much modern js and other features they can support while keeping true to the reasons for the fork

I feel like there ought to be a compromise between keeping the cul de sacs of web history supported, and 'just' supporting the latest browsers. SE supported IE for much longer than it ought to have had, and it had much bigger reach. Basically - it would be nice to find the point where we can get the best reach for the least effort

With something like silk, its very much amazon dropping support on those devices.It might literally be a specific build for a specific machine.

Answer 4

Stack Overflow states their support for browsers here:

Stack Overflow supports the last two stable versions of major browsers. This does not include beta/dev releases, which are not supported.

Therefore it is unlikely these 'issues' will be fixed. You mention that the dev team have generously fixed previous issues only occuring on old browsers, but dbc's answer gives clues as to why these changes aren't the same. The optional chaining syntax cannot be polyfilled unlike previous issues which are generally caused by new features (which can be polyfilled.)

Additionally, on SE's JavaScript migration post, optional chaining has previously been mentioned with no response from SE.

With these blockers in mind, the only way to mitigate these issues is either for SE to restrict the syntax they use for a sliver of users or for these users to update their browsers. There may be a fork of the Firefox version you mention that implements a JavaScript engine that supports ES6 features like optional chaining, but I am not aware of any.