fix: should now inject interaction buttons properly on post detail page

[hueyy]

See #84 (comment)

[rugk]

Okay, tested it practically (ref):

1. seems mostly fixed, however only when I open the link directly/reload the page. If I click the link here on GitHub, it again does not detect the injection… (reproducible) 😢 (I wonder whether that is, because of some PWA stuff or because of preloading/caching and/or a timing bug/race condition or whatever…)
2. Does still not work for me. STR:
3. I open https://mastodon.social/@drewtoothpaste/109393612157338955 in a new tab (paste in URL)
4. (optionally) click an interactuion button to confirm it initially works
5. now navigate somewhere else (the back button does not work as we have not naviagted from somewhere), e.g. by clicking on the link to the profile of the instance admin:
   
6. Okay, IMHO it's good you cannot reproduce this. I still can. But I guess it's related to my target instance (chaos.social) then.
7. If I am in (1) state, i.e. a broken state, where it does not work, it resproducibly fails, i.e. even the follow button does nto work, no matter how much I navigate around. (Actually my understanding is each URL change should cause the injection, should not it? Or no, actually only when the tab is loaded/a new site is loaded? If so, then we have a problem with the injection of course.

If the injection should be a problem and makes it less (sporadically) buggy, I BTW, would be fine for introducing the "Acess all sites" permissions (note just to explain the permission in the permission.md document then).

Mastodon v4.0.2
Firefox 106.0.4
add-on code: 2110424

[rugk]

Hmm I am unsure what the problem here is… but I have some tips anyway.

[rugk]

missed a comment

[hueyy]

Thanks for the detailed writeup! Yes, now I can reproduce it. The problem is with the injection. It seems that when you navigate to a different page on a PWA browser.tabs.executescript() is called but somehow the content script is not re-run. Let me experiment a bit, there should be a way around this.

[hueyy]

Figured it out. So it appears that Firefox will wait for the Return Value of the content_script to resolve before re-running the content_script on the same tab, unless the tab reloads. The return value of the mastodonInject.js content_script was not returning quickly enough for 2 reasons:

1. the init() function was awaiting a waitForElement call with a timeout of 20s; and
2. the declaration of the constant TIMEOUT_DURATION at the top of the file caused an error to be thrown on subsequent content_script executions because it appears the same context is used for subsequent executions

@rugk, trouble you to test it again and confirm the issue has been resolved.

[rugk]

Please also note we have a manual testing guide, so if you could test it manually based on that guide, that would be helpful, too: https://github.com/rugk/mastodon-simplified-federation/wiki/Testing

Please note the guide is partially outdated, feel free to correct that… see #45.

[rugk]

forget this part

I managed to find a problem: If I use the link from the guide here and quickly click on any interaction button/star, while the progress bar at the top is still loading, I get the same issue again, it's still the old dialog.

I assume the content script is only injected/we trigger only when the page has fully loaded? Or actually the MutationObserver can trigger earlier, can't it?

Addendum: Managed to reproduce this twice and I guess it was because I was fast hmm... maybe one also needs to load a toot that is not yet cached in your browser and poztentially large (image or so).

Okay, tried to reproduce it again via network throtteling, I cannot: https://firefox-source-docs.mozilla.org/devtools-user/network_monitor/throttling/index.html

As soon as the star is there I click on it and here it goes… though hmm, maybe of course network throtteling does only throttle the network not JS… 🙃

Ahhh, I did not update my testing code I am sorrry…

Back testing 8490dbe

So with throtteling in 2G good/3G scenarious (may not be relevant) I noticed when I click on a toot at the top right (the date) to open it and then click any of the interaction buttons, it does not work either.
Going back to the account overview (not the detailed toot view) …and there it works again though.

Also scrolling down and loading new stuff via AJAX works.
Opening the link (click on date again), in a new tab (middle click via mouse e.g.) works, too.

It reproducibly fails to inject the stuff when I navigate from account overview to a single toot. Navigation via browser back/forwards buttons yields in the same result.

[rugk]

the declaration of the constant TIMEOUT_DURATION at the top of the file caused an error to be thrown on subsequent content_script executions because it appears the same context is used for subsequent executions

Ahh, yeah… that is a good thing you noticed! However, your solution of removing the const variable is not a proper solution IMHO.

Actually, do we really want to inject the content script multiple times? I think, actually, wo don't! It has all things to stay there and keep reacting on things that happen, AFAIK.

So, instead, could not we maybe check for a "if isDeclared(SOME_CONSTANT_THAT_SHIOWS_WE_INJECTED_THIS_SCRIPT)" and then break processing, so nothing gets reinjected? (This is pseudo code of course.)

Related problems (not looked into details): https://stackoverflow.com/questions/74624848/inject-content-script-only-once-in-a-webpage and https://discourse.mozilla.org/t/why-is-it-soo-hard-to-inject-a-content-script-only-once-at-site-load/38903 (ouch, I just saw that last one was from past self here, actually 🙈 )

[rugk]

+ see my comment above, reinjection complicates stuff and may cause weird side-effects indeed, so let's prevent that from happening.

[hueyy]

It seems to be difficult to re-run the injection functions when the Mastodon uses the History API to navigate (e.g. from toot detail to profile page) because Firefox does not emit a popstate, hashchange, or pageshowevent. This is apparently to prevent malicious websites from hijacking exit events, but it does make our job more difficult.

Instead, I have used a new MutationObserver to check for new UI elements. I have removed the previous MutationObserver and have carefully tailored the CSS selector for the new one, so I think the overhead of monitoring UI changes should be reasonable. I have tried various more specific CSS selectors, but besides the risk of breaking changes if Mastodon changes its UI, the element selected may also be replaced by some actions (e.g. the main column .column[role="region"] is occasionally replaced), hence any MutationObserver observing that becomes ineffective.

[rugk]

Code-wise LGTM, let me test.

[rugk]

BTW while testing I had #88, but now seems to work or I am not sure really.

[rugk]

Another unfortunate problem

I have to say that, unfortunately, now, the add-on also triggers on the "usual" Mastodon page i.e. my own instance and tries to redirect stuff back to my own instance quite often.
I.e. some interaction buttons (mostly noticed the "reply" button), just trigger it, which is obviously quite bad.

Obviously, we should avoid that… 🙃

[hueyy]

@rugk Oops, I realised this happens when you open a remote instance page in a background tab, because the executeScript function injects into the active tab by default. Fixed that by specifying the tabId!

[rugk]

Code-wise LGTM.