2
5
Fork
You've already forked userscripts
2

YT2Invidio: Delay rewrite? Rewrite on click? #5

Open
opened 2020年12月03日 02:29:38 +01:00 by ltguillaume · 15 comments
Contributor
Copy link

I've found that on some websites, the links weren't rewritten, most likely because of delayed results fetching, for example in search engines like Searx.

Perhaps a simple delay of rewriting would do in most cases, without being annoying.

// Get the Invidious instance to use for rewrite
setTimeout(() => {
 GM.getValue('YT2IConfig',JSON.stringify(defaultConfig)).then(function(result) {
 rewriteLinks(result);
 });
}, 2000);

A wholly different approach could be to rewrite only when a link is clicked. This will probably create a few compatibility issues to be mitigated, although I've been using code like this for (optionally reviewable) direct links in Gmail for quite a while (but that's just one site).

document.addEventListener('click', e => {
 ~"if the URL doesn't contain any of the to be rewritten websites" 
 return;
 e.preventDefault();
 location.assign(rewriteLink(e.target));
}, true);
I've found that on some websites, the links weren't rewritten, most likely because of delayed results fetching, for example in search engines like Searx. Perhaps a simple delay of rewriting would do in most cases, without being annoying. ``` // Get the Invidious instance to use for rewrite setTimeout(() => { GM.getValue('YT2IConfig',JSON.stringify(defaultConfig)).then(function(result) { rewriteLinks(result); }); }, 2000); ``` A wholly different approach could be to rewrite only when a link is clicked. This will probably create a few compatibility issues to be mitigated, although I've been using code like this for (optionally reviewable) direct links in Gmail for quite a while (but that's just one site). ``` document.addEventListener('click', e => { ~"if the URL doesn't contain any of the to be rewritten websites" return; e.preventDefault(); location.assign(rewriteLink(e.target)); }, true); ```
Owner
Copy link

Perhaps a simple delay of rewriting would do in most cases

Have you tested that? If it really helps, I'm not opposed (though I cannot remember having had this issue with Searx – and I'm using Searx a lot, it's two of my default search engines). Though it wouldn't help with pages loading content dynamically (like all that NodeCrap, where all you get with JS turned off is either an empty page or a text saying "this application (sic!) needs Javascript"). Unfortunately, that's also true for Mastodon. Not sure if your "click" approach would work there.

rewrite only when a link is clicked

Lacks transparency. You hover a link, it shows "host-A" – but when you click, it goes to "host-B". I'd find that a bit ugly and would prefer not to. Unless mitigated in a way it's obvious – like rewriting on hover, if that's possible.

> Perhaps a simple delay of rewriting would do in most cases Have you tested that? If it really helps, I'm not opposed (though I cannot remember having had this issue with Searx – and I'm using Searx a lot, it's two of my default search engines). Though it wouldn't help with pages loading content dynamically (like all that NodeCrap, where all you get with JS turned off is either an empty page or a text saying "this application (sic!) needs Javascript"). Unfortunately, that's also true for Mastodon. Not sure if your "click" approach would work there. > rewrite only when a link is clicked Lacks transparency. You hover a link, it shows "host-A" – but when you click, it goes to "host-B". I'd find that a bit ugly and would prefer not to. Unless mitigated in a way it's obvious – like rewriting on hover, if that's possible.
Author
Contributor
Copy link

Perhaps a simple delay of rewriting would do in most cases

Have you tested that? If it really helps, I'm not opposed (though I cannot remember having had this issue with Searx – and I'm using Searx a lot, it's two of my default search engines). Though it wouldn't help with pages loading content dynamically (like all that NodeCrap, where all you get with JS turned off is either an empty page or a text saying "this application (sic!) needs Javascript"). Unfortunately, that's also true for Mastodon. Not sure if your "click" approach would work there.

It'll work for some pages, yeah. However, I'm using infinite scroll on Searx, too, so after the first page, it won't rewrite results anyway. I was thinking there'd perhaps be a way to set up a hook for fetch/$.ajax asynchronous stuff, but I honestly don't know enough about that.

rewrite only when a link is clicked

Lacks transparency. You hover a link, it shows "host-A" – but when you click, it goes to "host-B". I'd find that a bit ugly and would prefer not to. Unless mitigated in a way it's obvious – like rewriting on hover, if that's possible.

Yes, that's true. That could be mitigated by rewriting on 'onmouseover' events as you say. I'll do some testing.

> > Perhaps a simple delay of rewriting would do in most cases > > Have you tested that? If it really helps, I'm not opposed (though I cannot remember having had this issue with Searx – and I'm using Searx a lot, it's two of my default search engines). Though it wouldn't help with pages loading content dynamically (like all that NodeCrap, where all you get with JS turned off is either an empty page or a text saying "this application (sic!) needs Javascript"). Unfortunately, that's also true for Mastodon. Not sure if your "click" approach would work there. It'll work for some pages, yeah. However, I'm using infinite scroll on Searx, too, so after the first page, it won't rewrite results anyway. I was thinking there'd perhaps be a way to set up a hook for fetch/$.ajax asynchronous stuff, but I honestly don't know enough about that. > > rewrite only when a link is clicked > > Lacks transparency. You hover a link, it shows "host-A" – but when you click, it goes to "host-B". I'd find that a bit ugly and would prefer not to. Unless mitigated in a way it's obvious – like rewriting on hover, if that's possible. Yes, that's true. That could be mitigated by rewriting on 'onmouseover' events as you say. I'll do some testing.
Owner
Copy link

but I honestly don't know enough about that.

Neither do I. This was requested before, and the pointers suggested implied some overhead I wasn't willing to take (apart from not being familiar with). I'd need to check the buss-words if you need them – but probably you can find them at Greasyfork yourself. Ah, there it is: MutationObserver, used e.g. by this script.

I'll do some testing.

Cool, thanks!

> but I honestly don't know enough about that. Neither do I. This was requested before, and the pointers suggested implied some overhead I wasn't willing to take (apart from not being familiar with). I'd need to check the buss-words if you need them – but probably you can find them at Greasyfork yourself. Ah, there it is: MutationObserver, used e.g. by [this script](https://greasyfork.org/en/scripts/375264-youtube-to-invidious). > I'll do some testing. Cool, thanks!
Author
Contributor
Copy link

See commit and comment ltGuillaume/userscripts@b1f03ee6eb

Ah yes, with MutationObserver it would trigger with every change, with an EventListener like mine it still triggers quite a bit, I agree.

Instead of 'mouseover', for my other script I just use 'click', which of course has no overhead, and open an input dialog with the cleaned URL. I can then change the URL or just press either OK/Enter to open it. Cancel can either not open it at all, or open the original URL, whatever floats your boat. That's probably not what you'd want for this one, though.

See commit and comment https://codeberg.org/ltGuillaume/userscripts/commit/b1f03ee6eb6a7f780b894593b33e37b45fad4c45 Ah yes, with MutationObserver it would trigger with every change, with an EventListener like mine it still triggers quite a bit, I agree. Instead of 'mouseover', for my other script I just use 'click', which of course has no overhead, and open an input dialog with the cleaned URL. I can then change the URL or just press either OK/Enter to open it. Cancel can either not open it at all, or open the original URL, whatever floats your boat. That's probably not what you'd want for this one, though.
Author
Contributor
Copy link

I like the // @exclude entries from that script, though.

I like the `// @exclude ` entries from that script, though.
Owner
Copy link

See commit and comment b1f03ee6eb

Ah, I see. You rewrite the links on hover. But is it really necessary to also overwrite the title? Consider a link like this is <a href='..' title='video of my cat'>Peter</a>, and <a href='..' title='video of my dog'>this</a> is Bob (sorry, cannot come up with something more impressive) – you see that would remove contextual details. It's unlikely the title was set to an URL before – so without rewrite, the URL would become visible on hover at the exact same place I'd expect the new one to show up: in one of the browser's bottom corners. Doesn't it do so for you, without rewriting the title attribute?

Ah yes, with MutationObserver it would trigger with every change, with an EventListener like mine it still triggers quite a bit, I agree.

And what's more, EventListener would only rewrite the "relevant" links (ignoring those you'd not click anyway) – that's what I like about the idea. Have you tried that on some "infinite scroll" page? Would it trigger even for new elements?

Hm, did we consider side-effects – like folks navigating using their keyboards? Would "mouseover" apply to that as well – or is there another event like "activated" => maybe "focus" (has focus) or "focusin" (just about to get the focus)? Which makes me think whether re-initializing the DOM tree on "scroll" might help with those Ajax pages (infinite scroll, Mastodon etc).

I like the // @exclude entries from that script, though.

For some reason I had decided against that (or even removed it, would need to check old versions if it once was there), don't remember exactly what it was. It's mitigated, though – just watch for if (location.hostname != videohost) etc. in the code. Ah, see the history:

v1.1.1 (2019年09月06日): do not exclude invidio.us but just ignore YT links there instead

So why? Take a look at the previous version's changelog:

v1.1.0 (2019年09月05日): add Twitter2Nitter

Get it? Excluding the sites would mean: no YT links rewritten on Nitter, no Twitter links on YT etc.

> See commit and comment b1f03ee6eb Ah, I see. You rewrite the links on hover. But is it really necessary to also overwrite the title? Consider a link like `this is <a href='..' title='video of my cat'>Peter</a>, and <a href='..' title='video of my dog'>this</a> is Bob` (sorry, cannot come up with something more impressive) – you see that would remove contextual details. It's unlikely the title was set to an URL before – so without rewrite, the URL would become visible on hover at the exact same place I'd expect the new one to show up: in one of the browser's bottom corners. Doesn't it do so for you, without rewriting the title attribute? > Ah yes, with MutationObserver it would trigger with every change, with an EventListener like mine it still triggers quite a bit, I agree. And what's more, EventListener would only rewrite the "relevant" links (ignoring those you'd not click anyway) – that's what I like about the idea. Have you tried that on some "infinite scroll" page? Would it trigger even for new elements? Hm, did we consider side-effects – like folks navigating using their keyboards? Would "mouseover" apply to that as well – or is there another event like "activated" => maybe "focus" (has focus) or "focusin" (just about to get the focus)? Which makes me think whether re-initializing the DOM tree on "scroll" might help with those Ajax pages (infinite scroll, Mastodon etc). > I like the `// @exclude` entries from that script, though. For some reason I had decided against that (or even removed it, would need to check old versions if it once was there), don't remember exactly what it was. It's mitigated, though – just watch for `if (location.hostname != videohost)` etc. in the code. Ah, see the history: > v1.1.1 (2019年09月06日): do not exclude invidio.us but just ignore YT links there instead So why? Take a look at the previous version's changelog: > v1.1.0 (2019年09月05日): add Twitter2Nitter Get it? Excluding the sites would mean: no YT links rewritten on Nitter, no Twitter links on YT etc.
Author
Contributor
Copy link

See commit and comment b1f03ee6eb

Ah, I see. You rewrite the links on hover. But is it really necessary to also overwrite the title? Consider a link like this is <a href='..' title='video of my cat'>Peter</a>, and <a href='..' title='video of my dog'>this</a> is Bob (sorry, cannot come up with something more impressive) – you see that would remove contextual details. It's unlikely the title was set to an URL before – so without rewrite, the URL would become visible on hover at the exact same place I'd expect the new one to show up: in one of the browser's bottom corners. Doesn't it do so for you, without rewriting the title attribute?

You're right, this isn't a good solution. I rewrote the title, because (at least in my browser), the tooltip at the bottom of the page that shows the URL does not update when the URL is being rewritten. If that is the case in more modern browsers (or there is a some way to refresh that (which I doubt), then it wouldn't be necessary. Another way to do this would be to just add [YT2I] or something to the title, so you can at least get a confirmation that the URL has been rewritten.

Ah yes, with MutationObserver it would trigger with every change, with an EventListener like mine it still triggers quite a bit, I agree.

And what's more, EventListener would only rewrite the "relevant" links (ignoring those you'd not click anyway) – that's what I like about the idea. Have you tried that on some "infinite scroll" page? Would it trigger even for new elements?

Yes, in my tests that worked perfectly fine.

Hm, did we consider side-effects – like folks navigating using their keyboards? Would "mouseover" apply to that as well – or is there another event like "activated" => maybe "focus" (has focus) or "focusin" (just about to get the focus)?

There are indeed some conditions that wouldn't trigger the EventListener, so another one for 'click' (which probably could reuse the exact same code) would be in order. I'm not sure if it matters whether the rewriting gets triggered before clicking if they use keyboard navigation, becuase I don't know where they'd check the actual URL, but I get your point.

Which makes me think whether re-initializing the DOM tree on "scroll" might help with those Ajax pages (infinite scroll, Mastodon etc).

If there's a different event type that could trigger the current code, that could also work, but scroll shouldn't be used, that's for sure: such an EventListener is triggered for pretty much each pixel scrolled, which is a real resource hog (yes, of course you can implement timeouts and/or minimal scrolling deltas, but it's still no good).

I like the // @exclude entries from that script, though.

For some reason I had decided against that (or even removed it, would need to check old versions if it once was there), don't remember exactly what it was. It's mitigated, though – just watch for if (location.hostname != videohost) etc. in the code. Ah, see the history:

v1.1.1 (2019年09月06日): do not exclude invidio.us but just ignore YT links there instead

So why? Take a look at the previous version's changelog:

v1.1.0 (2019年09月05日): add Twitter2Nitter

Get it? Excluding the sites would mean: no YT links rewritten on Nitter, no Twitter links on YT etc.

Shoot, pretty stupid I didn't think about that...

Aaaah I love those quote-in-quote email-style replies 😛

> > See commit and comment b1f03ee6eb > > Ah, I see. You rewrite the links on hover. But is it really necessary to also overwrite the title? Consider a link like `this is <a href='..' title='video of my cat'>Peter</a>, and <a href='..' title='video of my dog'>this</a> is Bob` (sorry, cannot come up with something more impressive) – you see that would remove contextual details. It's unlikely the title was set to an URL before – so without rewrite, the URL would become visible on hover at the exact same place I'd expect the new one to show up: in one of the browser's bottom corners. Doesn't it do so for you, without rewriting the title attribute? You're right, this isn't a good solution. I rewrote the title, because (at least in my browser), the tooltip at the bottom of the page that shows the URL does not update when the URL is being rewritten. If that is the case in more modern browsers (or there is a some way to refresh that (which I doubt), then it wouldn't be necessary. Another way to do this would be to just add `[YT2I]` or something to the title, so you can at least get a confirmation that the URL has been rewritten. > > Ah yes, with MutationObserver it would trigger with every change, with an EventListener like mine it still triggers quite a bit, I agree. > > And what's more, EventListener would only rewrite the "relevant" links (ignoring those you'd not click anyway) – that's what I like about the idea. Have you tried that on some "infinite scroll" page? Would it trigger even for new elements? Yes, in my tests that worked perfectly fine. > Hm, did we consider side-effects – like folks navigating using their keyboards? Would "mouseover" apply to that as well – or is there another event like "activated" => maybe "focus" (has focus) or "focusin" (just about to get the focus)? There are indeed some conditions that wouldn't trigger the EventListener, so another one for 'click' (which probably could reuse the exact same code) would be in order. I'm not sure if it matters whether the rewriting gets triggered before clicking if they use keyboard navigation, becuase I don't know where they'd check the actual URL, but I get your point. > Which makes me think whether re-initializing the DOM tree on "scroll" might help with those Ajax pages (infinite scroll, Mastodon etc). If there's a different event type that could trigger the current code, that could also work, but `scroll` shouldn't be used, that's for sure: such an EventListener is triggered for pretty much each pixel scrolled, which is a real resource hog (yes, of course you can implement timeouts and/or minimal scrolling deltas, but it's still no good). > > I like the `// @exclude` entries from that script, though. > > For some reason I had decided against that (or even removed it, would need to check old versions if it once was there), don't remember exactly what it was. It's mitigated, though – just watch for `if (location.hostname != videohost)` etc. in the code. Ah, see the history: > > > v1.1.1 (2019年09月06日): do not exclude invidio.us but just ignore YT links there instead > > So why? Take a look at the previous version's changelog: > > > v1.1.0 (2019年09月05日): add Twitter2Nitter > > Get it? Excluding the sites would mean: no YT links rewritten on Nitter, no Twitter links on YT etc. Shoot, pretty stupid I didn't think about that... Aaaah I love those quote-in-quote email-style replies 😛
Owner
Copy link

Sorry for the long delay – was busy on other tasks...

Meanwhile experimented with document.addEventListener("DOMNodeInserted" (to catch dynamically loaded content) – but that seems to have the same horrible side-effects as "scroll", so I've abandoned that.

But, as that needed wrapping the initial load into a procedure to be called, I left that wrapper in the code – and instead of the EventListener, registered another GM MenueCommand: now you can manually trigger a rewrite. Tested it: works fine with Mastodon. If you could test as well (it's committed as v1.5.1) and confirm, we might consider that a compromise: virtually no overhead while running, avoids the side-effects discussed; just not that comfortable to use as it requires walking some menues. But maybe it's possible to assign it a hotkey? If so, suggestions are welcome (also concerning which key to bind by default).

Aaaah I love those quote-in-quote email-style replies 😛

Yeah, me too 😄

Sorry for the long delay – was busy on other tasks... Meanwhile experimented with `document.addEventListener("DOMNodeInserted"` (to catch dynamically loaded content) – but that seems to have the same horrible side-effects as "scroll", so I've abandoned that. But, as that needed wrapping the initial load into a procedure to be called, I left that wrapper in the code – and instead of the EventListener, registered another GM MenueCommand: now you can manually trigger a rewrite. Tested it: works fine with Mastodon. If you could test as well (it's committed as v1.5.1) and confirm, we might consider that a compromise: virtually no overhead while running, avoids the side-effects discussed; just not that comfortable to use as it requires walking some menues. But maybe it's possible to assign it a hotkey? If so, suggestions are welcome (also concerning which key to bind by default). > Aaaah I love those quote-in-quote email-style replies 😛 Yeah, me too 😄
Author
Contributor
Copy link

Personally I don't see a manual trigger as a viable compromise.

You mentioned the lack of transparency with the rewrite-on-click, this manual trigger also lacks transparency, because you need to track the rewritten links yourself.

In my fork I've implemented the choice to rewrite on click or on hover, and I want to set Alt+Click to "open without rewrite".

I think it's better to just assume a link is rewritten than having to manually trigger rewrites on every page change.

Personally I don't see a manual trigger as a viable compromise. You mentioned the lack of transparency with the rewrite-on-click, this manual trigger also lacks transparency, because you need to track the rewritten links yourself. In my fork I've implemented the choice to rewrite on click or on hover, and I want to set Alt+Click to "open without rewrite". I think it's better to just assume a link is rewritten than having to manually trigger rewrites on every page change.
Owner
Copy link

Personally I don't see a manual trigger as a viable compromise.

Let's say I see it as "works for me – somehow..." – and at least better than before.

You mentioned the lack of transparency with the rewrite-on-click, this manual trigger also lacks transparency, because you need to track the rewritten links yourself.

Other than with "rewrite on click", you have "rewrite on hover" and thus see it before you click – same as it is with the automatically rewritten links. so it's consistent. What I meant by lack of transparency is if it says "link goes to A" on hover, but when you click it it goes to B. And I prefer the current "manual trigger for dynamic content" to a two-click solution, TBH.

I think it's better to just assume a link is rewritten than having to manually trigger rewrites on every page change.

Yes and no. Just to assume, then click, and find out it did not rewrite for some reason is something I do not find acceptable. But that would be a risk we run. And Alt-click brings us back to the "keyboard only" issue.

If I see e.g. a YT link has not been rewritten, and I can simply hit a hotkey to trigger the rewrite – I find that much preferable than to always have to hit a hotkey while clicking 😉

> Personally I don't see a manual trigger as a viable compromise. Let's say I see it as "works for me – somehow..." – and at least better than before. > You mentioned the lack of transparency with the rewrite-on-click, this manual trigger also lacks transparency, because you need to track the rewritten links yourself. Other than with "rewrite on click", you have "rewrite on hover" and thus see it before you click – same as it is with the automatically rewritten links. so it's consistent. What I meant by lack of transparency is if it says "link goes to A" on hover, but when you click it it goes to B. And I prefer the current "manual trigger for dynamic content" to a two-click solution, TBH. > I think it's better to just assume a link is rewritten than having to manually trigger rewrites on every page change. Yes and no. Just to assume, then click, and find out it did *not* rewrite for some reason is something I do *not* find acceptable. But that would be a risk we run. And <kbd>Alt</kbd>-click brings us back to the "keyboard only" issue. If I see e.g. a YT link has not been rewritten, and I can simply hit a hotkey to trigger the rewrite – I find that much preferable than to *always* have to hit a hotkey *while* clicking :wink:
Author
Contributor
Copy link

Just to assume, then click, and find out it did not rewrite for some reason is something I do not find acceptable.

Yes I understand that stance, too.

I find that much preferable than to always have to hit a hotkey while clicking

No, I meant that Alt+Click would prevent rewriting the link. No hotkey == rewrite.

But I understand that if rewrites somehow fail, it would be annoying (hence the rewrite on hover).

That's just an extra that could also be achieved without a keyboard shortcut by (temporarily) disabling the script, or there could be an option to temporarily disable (without reloading the page, because links are only rewritten on click).

>Just to assume, then click, and find out it did not rewrite for some reason is something I do not find acceptable. Yes I understand that stance, too. >I find that much preferable than to always have to hit a hotkey while clicking No, I meant that Alt+Click would _prevent_ rewriting the link. No hotkey == rewrite. But I understand that _if_ rewrites somehow fail, it would be annoying (hence the rewrite on hover). That's just an extra that could also be achieved without a keyboard shortcut by (temporarily) disabling the script, or there could be an option to temporarily disable (without reloading the page, because links are only rewritten on click).
Owner
Copy link

No, I meant that Alt+Click would prevent rewriting the link. No hotkey == rewrite.

Oh – OK, then I got that wrong. Combined with ...

rewrite on hover

that's something I find absolutely suitable. So basically, based on the recent version, you'd simply wrap the direct call to the new "initialisation procedure" doRewrite into an EventListener for a:hover? Can you send me that line so I can give it a try? Sounds interesting. In fact, who doesn't read the code wouldn't notice the difference – as you only see the link when hovering but cannot tell if it was just rewritten then or already before.

Yes, I'm aware I just over-simplified – of course you didn't mean to rewrite all links on a page when hovering one of them. The hover event would just run the part currently inside the loop, while the init would set up the variables etc. and run the stuff for embeds. Still, I'd like to try that one locally (just defining that listener when on specific sites, to see how it works).

But I understand that if rewrites somehow fail, it would be annoying

Oh yeah, that could be embarrassing... Which is why I cannot accept the following:

because links are only rewritten on click

I'm fine with "on hover". But I want to see where I end up before I click.

> No, I meant that Alt+Click would *prevent* rewriting the link. No hotkey == rewrite. Oh – OK, then I got that wrong. Combined with ... > rewrite on hover that's something I find absolutely suitable. So basically, based on the recent version, you'd simply wrap the direct call to the new "initialisation procedure" `doRewrite` into an EventListener for `a:hover`? Can you send me that line so I can give it a try? Sounds interesting. In fact, who doesn't read the code wouldn't notice the difference – as you only see the link when hovering but cannot tell if it was just rewritten then or already before. Yes, I'm aware I just over-simplified – of course you didn't mean to rewrite all links on a page when hovering one of them. The hover event would just run the part currently inside the loop, while the init would set up the variables etc. and run the stuff for embeds. Still, I'd like to try that one locally (just defining that listener when on specific sites, to see how it works). > But I understand that if rewrites somehow fail, it would be annoying Oh yeah, that could be embarrassing... Which is why I cannot accept the following: > because links are only rewritten on click I'm fine with "on hover". But I want to see where I end up *before* I click.
Author
Contributor
Copy link

https://codeberg.org/ltGuillaume/userscripts/commits/branch/master

I'm guessing there's a better way to store the original link than to use the hreflang attribute for it, but I'm not sure what.

In order to support default behavior of Ctrl+Click and Shift+Click, I tried the following ltGuillaume/userscripts@93eb59b445 which works in Chromium, but not Firefox... No clue as to why, because https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent suggests full support.

https://codeberg.org/ltGuillaume/userscripts/commits/branch/master I'm guessing there's a better way to store the original link than to use the `hreflang` attribute for it, but I'm not sure what. In order to support default behavior of Ctrl+Click and Shift+Click, I tried the following https://codeberg.org/ltGuillaume/userscripts/commit/93eb59b445d4e759fc566c327b5fb4c659c56903 which works in Chromium, but not Firefox... No clue as to why, because https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent suggests full support.
Author
Contributor
Copy link

ltGuillaume/userscripts@46c0339457 seems to work nicely:

  • No strange click workarounds/programmatic clicks
  • Using useCapture in the EventListeners rewrites the links in to to use the normal browser clicks. As such, both Ctrl+click & Shift+click, as well as Alt+Ctrl+click & Alt+Shift+click to open the original link in new tab/window works in Chromium (and to Alt+Ctrl+click in Firefox)
  • Alt + hover link also restores the original link
https://codeberg.org/ltGuillaume/userscripts/commit/46c03394572abe12030338e69f5c77845d78f375 seems to work nicely: - No strange click workarounds/programmatic clicks - Using useCapture in the EventListeners rewrites the links in to to use the normal browser clicks. As such, both Ctrl+click & Shift+click, as well as Alt+Ctrl+click & Alt+Shift+click to open the original link in new tab/window works in Chromium (and to Alt+Ctrl+click in Firefox) - Alt + hover link also restores the original link
Author
Contributor
Copy link

Top 6 commits https://codeberg.org/ltGuillaume/userscripts/commits/branch/master are new since last comment.

Top 6 commits https://codeberg.org/ltGuillaume/userscripts/commits/branch/master are new since last comment.
Sign in to join this conversation.
No Branch/Tag specified
master
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
izzy/userscripts#5
Reference in a new issue
izzy/userscripts
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?