Mastodon: Web interface no longer works on SeaMonkey

[logological]

Some time between 15 January and 31 January 2020, the Mastodon web interface stopped working with the SeaMonkey web browser.

Expected behaviour

Visiting https://mastodon.social/web/ should display my toot feed as usual.

Actual behaviour

I get a web page with the following message:

Due to a bug in our code or a browser compatibility issue, this page could not be displayed correctly.

Try refreshing the page. If that does not help, you may still be able to use Mastodon through a different browser or native app.

Mastodon v3.1.0rc1 · Report issue · Copy stacktrace to clipboard

The stack trace is as follows:

j/<@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:130407
a/</</<@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:283757
[603]/nt</n.componentWillMount@https://static-cdn.mastodon.social/packs/js/application-793cd168f296b105e62f.chunk.js:1:42120
Io@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1010792
Ji@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1026514
Ms@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1064493
Pu@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1048783
Tu@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1048708
wu@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1046048
gu@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1042792
ac@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1070799
lc/<@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1072032
ku@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1046399
lc@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1072017
hc.render@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:1073946
[603]/t.default/<@https://static-cdn.mastodon.social/packs/js/application-793cd168f296b105e62f.chunk.js:1:54073
r@https://static-cdn.mastodon.social/packs/js/common-30195a8da87a7d8bae6e.js:2:193671
[603]/t.default@https://static-cdn.mastodon.social/packs/js/application-793cd168f296b105e62f.chunk.js:1:53957
[496]/<@https://static-cdn.mastodon.social/packs/js/application-793cd168f296b105e62f.chunk.js:1:219

Steps to reproduce the problem

1. Using SeaMonkey, visit https://mastodon.social/web/

Specifications

According to the error message I received, the web server is running Mastodon v3.1.0rc1.

I'm using the latest stable release of SeaMonkey, which has the following user-agent string:

Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5

[STPKITT]

I have the same issue on Firefox 56.0.2.

[ladistroy]

Same problem with my account on https://mstdn.io/web/ and Seamonkey last version...

[lmachucab]

Same on Seamonkey 2.49.5 (latest stable AFAIK), however I can mostly reproduce this issue when trying to explore or login to any instance where I have an account. So long as I don't try to login (or so long as I delete stored login), or so long as I don't go to the explore / discover pages, content is shown correctly, albeit it loads noticeably slower than in previous iterations.

My stack trace matches almost exactly the one in the OP.

[lmachucab]

I can replicate the problem with FF 60 (ESR) on a mostly clean profile with only uBlock Origin for testing. Haven't tested with a mostly clean FF 68 (ESR) profile yet.

Any idea what was implemented in (apparently) v3.1.1 or slightly before that would break old-but-not-too-old stuff? Or any way we can get better logs client-side than the stacktrace?

[lmachucab]

Strangely enough, netsurf of all things seems to work correctly as I was able to use it to authenticate and request codes for logging in using a desktop app. So I'm assuming this is absolutely JS related.

[laaber]

Same problem with Waterfox (56.2.1) since my instance's admin upgraded from 3.0.1 to 3.1.1.
/settings/profile is still accessible, though. So Ithink it's a JS-issue and was introduced between 3.0.1 and 3.1.0rc,, the OP's version.

[ThibG]

I can replicate the problem with FF 60 (ESR) on a mostly clean profile with only uBlock Origin for testing. Haven't tested with a mostly clean FF 68 (ESR) profile yet.

This seems unlikely to be the same issue, as this one is caused by our use of Promise.prototype.finally, which has been implemented in Firefox 58 according to MDN.

Any idea what was implemented in (apparently) v3.1.1 or slightly before that would break old-but-not-too-old stuff? Or any way we can get better logs client-side than the stacktrace?

What caused the original report stacktrace is the use of Promise.prototype.finally. There's a PR open to provide a better stacktrace, but for now, your best bet is to look at the browser's console, unfortunately. You can also recover most (but not all, e.g., not the error itself) by using something like http://sourcemaps.info/

Browsers not supporting that particular API have long been unsupported by their vendors, but as the reports show, they're still being used, so it may be worth working around that issue.

[logological]

Thanks for the fix, though I'm not sure it's fair to say that the browsers in question are "years old" or have "long been unsupported by their vendors". The latest version of SeaMonkey referenced in the original report was released only a few weeks ago. Its features are lagging behind Firefox a bit but it does include all the Firefox security patches up to and including last month.

[lmachucab]

A browser being "years old" (not even true in terms of Seamonkey's stable releases:

Released September 4, 2019

) is not the same as being unsupported - it could simply mean it's in stable status (which could involve eg.: not implementing evolving, incomplete or controversial APIs). If your application is using a specific API exposed to the web, it should be able to detect its availability and fallback gracefully - or rather, the framework your application is using should. Maybe this should be also forwarded as a bug report to whatever the relevant upstream is, since I'm pretty sure Mastodon is not coded from the ground scratch up.

In the meantime: is there anything that can be implemented client-side (a userscript, an extension, etc) that can provide a graceful fallback? This situation makes me think for all its openness, Mastodon is not as amicable or responsible to web users as eg.: Twitter which works in my lightweight phone browser with JS disabled.

[lmachucab]

I'm still seeing this in all instances. I'm not sure this should register as [closed] yet.

[ThibG]

(which could involve eg.: not implementing evolving, incomplete or controversial APIs). If your application is using a specific API exposed to the web, it should be able to detect its availability and fallback gracefully - or rather, the framework your application is using should. Maybe this should be also forwarded as a bug report to whatever the relevant upstream is, since I'm pretty sure Mastodon is not coded from the ground scratch up.

The function used is part of Javascript, it's not something exotic or controversial. It is true, though, that it is a relatively new addition (added to the EcmaScript draft in early 2018), but that has been overlooked, as it has long been implemented in major browsers even before that.

I'm still seeing this in all instances. I'm not sure this should register as [closed] yet.

The issue tracker tracks the development version of Mastodon, in which it is fixed.

[ThibG]

In the meantime: is there anything that can be implemented client-side (a userscript, an extension, etc) that can provide a graceful fallback?

I am not sure. If you could somehow inject https://www.npmjs.com/package/promise.prototype.finally before loading Mastodon's code, this would fix it. But I'm not familiar with userscripts.

This situation makes me think for all its openness, Mastodon is not as amicable or responsible to web users as eg.: Twitter which works in my lightweight phone browser with JS disabled.

Maintaining one client (the Web UI) is already quite some work. But unlike Twitter, Mastodon doesn't lock down its API, and lets you use other clients (mobile clients, other clients like pinafore, or brutaldon, etc.). Of course, any JS-less web client would require you to trust the server hosting it, and in that sense, a JS-less interface bundled with Mastodon would be useful, but it's a lot of additional work.