"Could not redirect due to an unexpected error" when attempting to boost a post on where unauthenticated access to public toots is not possible

Bug description

When I click the Boost button to try to boost a remote post, I get an error notification from the addon that says "Could not redirect due to an unexpected error". Following the account does seem to work, however.

Steps to reproduce

Open a remote post like this one
Click the "boost" icon.

Actual behavior

A standard Mastodon popup appears, and a notification popup also appears:

Expected behavior

The simplified federation popup appears to confirm you want to boost the post. Or the post is opened in the user's local mastodon feed.

System

Operating system and version: Gentoo linux 5.15.41
Browser and version: Firefox 91.10.0esr
Add-on version: 1.3

Thanks for the report.

Is this always reproducible?

Also, if you have that error, could you please go to about:debugging in Firefox, find the extension and debug it there? Then reproduce the issue please. You get standard developer tools.

Could you copy potential log messages from there please?

For more information, see this guide: https://extensionworkshop.com/documentation/develop/debugging/#debugging-background-scripts

XHR GET https://types.pl/api/v1/statuses/108431355656120911
[HTTP/2 401 Unauthorized 140ms]

	
GET
	https://types.pl/api/v1/statuses/108431355656120911
Status 401
Unauthorized
Version HTTP/2
Transferred 1.28 KB (54 B size)
Referrer Policy strict-origin-when-cross-origin

    	
    cache-control
    	no-cache
    content-encoding
    	gzip
    content-type
    	application/json; charset=utf-8
    date
    	Tue, 07 Jun 2022 22:36:36 GMT
    permissions-policy
    	interest-cohort=()
    referrer-policy
    	same-origin
    server
    	Mastodon
    set-cookie
    	_mastodon_session=<snip>; path=/; secure; HttpOnly; SameSite=Lax
    strict-transport-security
    	max-age=63072000; includeSubDomains
    vary
    	Accept, Accept-Encoding, Origin
    x-clacks-overhead
    	GNU Natalie Nguyen
    x-content-type-options
    	nosniff
    X-Firefox-Spdy
    	h2
    x-frame-options
    	DENY
    x-ratelimit-limit
    	300
    x-ratelimit-remaining
    	299
    x-ratelimit-reset
    	2022-06-07T22:40:00.351800Z
    x-request-id
    	<snip>
    x-runtime
    	0.004310
    x-xss-protection
    	0
    	
    Accept
    	*/*
    Accept-Encoding
    	gzip, deflate, br
    Accept-Language
    	en-US,en;q=0.5
    Connection
    	keep-alive
    Cookie
    	_mastodon_session=<snip>
    Host
    	types.pl
    Sec-Fetch-Dest
    	empty
    Sec-Fetch-Mode
    	cors
    Sec-Fetch-Site
    	same-origin
    User-Agent
    	MastodonSimplifiedFederation (v1.3; https://github.com/rugk/mastodon-auto-follow; on Mozilla Firefox)
----
Unknown localization message “mastodon – simplified federation!” failed to redirect Notifications.js:26
----
Error: "types.pl" .
    MastodonApiError moz-extension://38563fd0-9d0d-4f85-b300-3bdd74308f5a/common/modules/MastodonApi.js:25
    getTootStatus moz-extension://38563fd0-9d0d-4f85-b300-3bdd74308f5a/common/modules/MastodonApi.js:95
    promise callback*getTootStatus moz-extension://38563fd0-9d0d-4f85-b300-3bdd74308f5a/common/modules/MastodonApi.js:93
    getTootUrl moz-extension://38563fd0-9d0d-4f85-b300-3bdd74308f5a/background/modules/Detect/Mastodon.js:155
    handleWebRequest moz-extension://38563fd0-9d0d-4f85-b300-3bdd74308f5a/background/modules/AutoRemoteFollow.js:77
    init moz-extension://38563fd0-9d0d-4f85-b300-3bdd74308f5a/background/modules/AutoRemoteFollow.js:155

----
Error: Please use $(ref:runtime.getURL). Notifications.js:31
    showNotification moz-extension://38563fd0-9d0d-4f85-b300-3bdd74308f5a/common/modules/Notifications.js:31

If I visit https://types.pl/api/v1/statuses/108431355656120911 directly, I get "This method requires an authenticated user" (it's for the public post I listed above).

So far it reproduces 100% on specific posts. But not every post will result in this. I've been trying to find a pattern (Mastodon version, locked accounts, forks such as glitch-soc) and so far I can't find a consistent pattern. I have seen it both work and fail with locked accounts. Something seems to be blocking that API's access in some situations. Not sure if its a server configuration or something like that.

Thanks a lot, first of all.

Error: Please use $(ref:runtime.getURL). Notifications.js:31

That is interesting and apparently a well-known issue, but also already fixed in the current dev version.

Also, that code part is only triggered when an actual notification is shown, so I guess it is not related to the origin error.

So I could reproduce this with the toot you mention, both with the stable version you use and the current dev version (973bbd9).

Problem

The problem seems to be the add-on tries to fetch information via the official Mastodon API at https://types.pl/api/v1/statuses/108431355656120911 However, the server you have there rejects that with “401 Unauthorized” and „This method requires an authenticated user” in the JSON body.
I rechecked the latest Mastodon API doc on that API endpoint (see “get View specific status”) there, and the authentication is optional and only needed for private toots, which makes sense. (read: „OAuth: Public for public statuses, user token + read:statuses for private statuses”). Note the version history explains this only applies to v2.7.0 of Mastodon or higher.
Looking around more it says this instance uses a custom Mastodon fork in v3.4.6+types, available on GitHub too.
As such, it's reasonable to conclude that either the fork or the server instance does not allow public toots to be API-accessed by public entities. I would strongly suggest to report this to them (e.g. via GitHub), as that's an API-incompatibility to the official Mastodon API (since v2.7.0 at least, apparently that fork was done before that version).

As for this add-on

That all said, while that original issue is an instance-specific issue, the add-on should have some way to deal with that.

For a high-level overview of how it works, please first see the Readme. All in all, it has some fallback inside and also does website/HTML scraping if it needs that (you can usually BTW see that if you can see the popup being loaded until the end/it takes some more seconds). That would/should work here, however, I've found a bug:

To implement such a fallback mechanism the extension races two promises against each other here, which have these two methods implemented:

mastodon-simplified-federation/src/background/modules/Detect/Mastodon.js

Line 164 in e340502

return Promise.race([getFromApiQuery, scrapFromHtml]);

Promise.race just has the issue that it also rejects as soon as a promise rejects, i.e. errors.
That's actually not what we want. That works, as long as the success comes before the error, but if the error is instant (which is nearly always the case here because the JSON API is faster than website scraping), then it fails.

We want to ignore errors. I.e. I found something like this SO questions asks for, which points to the modern browser-implemented solution called Promise.any.

This isn't only seen on that fork, unfortunately. I am seeing it for this post, for example:

https://mellified.men/@srol/108472559455355925

That instance is on mainline 3.5.2 Mastodon. Just to clarify the issue's scope. I still haven't discovered specifically what differentiates the instances with the issue, and the instances without. Though it does seem to depend on the instance. So presumably it's some server setting.

I believe it's probably caused by this setting being unchecked.

Ah interesting, thanks for your information. It's indeed the same issue. Anyway my PR should fix/handle that, too.

Interesting though that even when I am not authenticated I can access them via the web interface, which makes that setting kinda dubious…

If this continues to be a problem, we could only implement a login via OAuth, which WebExtensions specifically support. However, that would not help here given that we would need to authenticate to foreign server… so uff…