Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support auto-redirection by <link> #106

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

saschanaz
Copy link

Fixes #105

For now I didn't touch the existing detection mechanism. It could also detect more pages by some heuristic with regex on page URLs, but I'll defer that part.

@saschanaz
Copy link
Author

Technically it could be faster with direct request redirection by reading HTTP headers, but:

  • That would require webRequestBlocking and would block Provide Chrome version #55
  • Misskey do not support headers but only HTML elements
  • Blocking all requests sounds very bad for general browser performance

@saschanaz
Copy link
Author

BTW, I wonder what's the best to do when one wants to see the original page without redirection (because the fetched page in the home server may not show the full information). I'm deferring that too 👀

@saschanaz saschanaz marked this pull request as draft March 28, 2023 11:28
@saschanaz
Copy link
Author

(This needs tests)

@rugk
Copy link
Owner

rugk commented Jun 20, 2023

Hi @saschanaz,
first of all, thanks for your first contribution to this project! 🎉 👍 🏅
I hope you'll like this project and enjoy hacking on it… 😃

I am really sorry about the late reply, but I am quite busy with other life stuff and my GitHub backlog is growing exponentially.

Anyway, thanks a lot for that contribution (and idea BTW). I have created a milestone for that feature as it would change the UX of this add-on completely/drastically, but in a good way IMHO.

@rugk rugk added this to the v3.0 milestone Jun 20, 2023
Copy link
Owner

@rugk rugk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I generally agree on keeping the old behavior as a fallback and for other instances etc.

@@ -163,6 +163,10 @@
"message": "Prevents the use of an extra tab and instead redirects the action on the main page.",
"description": "This is an option shown in the add-on settings."
},
"optionRedirectImmediately": {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for introducing a setting!

IMHO, for a good UX we should then have two settings (both being enabled by default I guess):

  • one like this here enabling the "instant redirect" and
  • one covering the "old" redirects

This would enable one to disable the old redirect style (e.g. because of missing features/unwanted redirects like #28).

return;
}

await NetworkTools.redirectToWebsite(homeUrl, tabId);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
await NetworkTools.redirectToWebsite(homeUrl, tabId);
return NetworkTools.redirectToWebsite(homeUrl, tabId);

Any special reason you use await instead of just returning the Promise? That could be helpful for error handling or so, that's why I'd prefer return if there is no reason.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm? I believe awaiting is more helpful, since an error will throw at await call site but not at return call site. And awaiting is anyway more consistent.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm this goes deep into the way promises may be handled and I would have said before it makes no difference at all whether to await here, because likely where this is called it is also awaited. And await is just a cooler syntax for then.

But what you say may be right too, the stacktrace may not lost thus last function then? But I am really unsure here, so a js snippet/proof or some source would help. I am always open to learn something new hehe. Otherwise I'd stand to what I said, I.e. remove the await, because that would be consistent to how it is done in the code base everywhere else.

// clear cache of settings
await AddonSettings.loadOptions();
if (await AddonSettings.get("redirectImmediately")) {
redirectByActivityPubLink(tabId, changeInfo.url);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not awaiting this is deliberate?

Maybe put a commend to make that clear…

@@ -15,6 +15,7 @@ import * as MisskeyDetect from "./Detect/Misskey.js";

import * as NetworkTools from "/common/modules/NetworkTools.js";
import * as MastodonRedirect from "./MastodonRedirect.js";
import { redirectByActivityPubLink } from "./ActivityPubRedirect.js";
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I usually prefer a "module-like style", i.e. import * and then do a ActivityPubRedirect.redirectByActivityPubLink() call that makes clear where the module is from.

@@ -99,3 +99,22 @@ export function getTootStatus(mastodonServer, localTootId) {
return response.json();
});
}

/**
* Resolves the ActivityPub object ID on a given server
Copy link
Owner

@rugk rugk Jun 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any link/ref to the ActivityPub spec to add to this doc to exlain what it is? I've found one before, but I don't know whether that is up-to-date.

@@ -6,5 +6,6 @@

export const DEFAULT_SETTINGS = Object.freeze({
ownMastodon: null,
redirectInMainWindow: false
redirectInMainWindow: false,
redirectImmediately: false,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not enabled by default?

@rugk
Copy link
Owner

rugk commented Jun 20, 2023

I am answering the questions here now here:

  • Use the injection code to add "open it in my home server" button (perhaps with a home icon) for some supported server implementations (so that one can see some extra info in the original page)
  • If not, add a position: absolute fallback popup with the same button on the top of the page

I can imagine both being useful. But a popup may actually be the coolest thing – maybe in the design of that "copy that link" popup Mastodon shows by default, so that would be a replacement for it and integrate more seemingly.

However, I have another idea:

  • What about saving the lastest redirected URL/toot/user, and – if that URL is opened again only then show that popup aka „Do you really want to redirect?“. In other words: Only redirect if the toot has not been recently redirected already.
    This would save the click in 80% of the cases while keeping the ability to see the original toot when you have a reason for that.

If you wanted a quick implementation/MVP of it, you could just treat it as „no i never want to redirect if the URL is opened again” and not implement the popup for now. Then you could test how it feels like when using and maybe we don't actually need a popup?

I could imagine this would be a quite intuitive way, or otherwise one cannot differentiate that that may be an error? I don't know whether and how we could communicate that, if so, but we could always make it an optional feature to be enabled in the settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support auto-redirection by <link rel=alternate type=application/activitypub+json>?
2 participants