Feature Request: Add option to always directly open unsupported media

[VimalMollyn]

First off, thanks for the awesome extension! Works like a charm!

I mostly use it to watch Lecture recordings, which are hosted on google drive (currently unsupported). For jumpcutter to work, I need to use the "open link directly" option - Do you think you could add a setting to make this a default option? Something like - always open links directly if possible.

Happy to help add this feature as well!

Thanks!
Vimal

[WofWca]

First off, thanks for the awesome extension!

I'm glad to be helpful!

Do you think a hotkey for this would be as good?

[VimalMollyn]

That would be perfect!

[WofWca]

Happy to help add this feature as well!

And by that you mean you're willing to implement it? Because I haven't yet decided on how I should license this project, so it's status quo is "all rights reserved".

[VimalMollyn]

Sure, I can take a stab at it. Let me see if I can get it working!

[WofWca]

Do you understand the implications of what I said about the license? Would you be willing to give me the intellectual rights for your changes?

[VimalMollyn]

Oh, as long as it's free and open source, I don't mind! :D

[WofWca]

Great, thanks!
Let me know if you have any questions.
Also would be cool to hear from you if you find something ugly in the codebase (there may be a lot).

[WofWca]

I think the final version of this feature should be implemented through the browser commands API, not the custom hotkeys code we have. Because the content script currently launches only when the page has finished loading (and I think for better performance it should be kept that way), so we can't attach a listener until that. But using the commands API we could listen to command strokes on the background and, if the page on which the "open directly" command has been executed, is still loading, then schedule the handling for later - wait for the content script to search the page for media elements, then open the active one's currentSrc in a new tab.
Also, in case there are several iframes on the page, it's probably the background script who should decide which one to choose, like it's done here:

jumpcutter/src/popup/App.svelte

Line 96 in df8d682

&& (!elementLastActivatedAt || message.elementLastActivatedAt > elementLastActivatedAt)

All this because users usually visit the same site and so they already know that the extension is not supported on it, so they usually open a video and then immediately want to execute the command. Would not be very cool if they had to spam it, waiting for the script to load.

[WofWca]

Also, after saying it out loud an idea visited me that maybe it would be even cooler if instead of a hotkey we'd offer a context menu option for links. I.e. you right-lick a link to a page with a video and there is an option "open directly". It opens a new tab, with the original link's URL, then finds the video and opens it directly.

Although there' s a bit of a problem that it currently won't attach to any video unless its currentTime > 0 or paused === false, so it would be opening the video directly not immediately but as soon as the user switches to the tab, which would be a bit nauseating:

jumpcutter/src/content/AllMediaElementsController.ts

Lines 464 to 492 in ecb3e71

	// Attach to the first new element that is not paused, even if we're already attached to another.
	// The thoguht process is like this - if such an element has been inserted, it is most likely due to the user
	// wanting to switch his attention to it (e.g. pressing the "play" button on a custom media player, or scrolling
	// a page with an infinite scroll with autoplaying videos).
	// It may be that the designer of the website is an asshole and inserts new media elements whenever he feels like
	// it, or I missed some other common cases. TODO think about it.
	for (const el of newElements) {
	if (!el.paused) {
	this.esnureAttachToElement(el);
	break;
	}
	}
	// Useful when the extension is disabled at first, then the user pauses the video to give himself time to enable it.
	if (!this.activeMediaElement) {
	for (const el of newElements) {
	if (
	el.currentTime > 0
	// It is possilble for an element to have `currentTime > 0` while having its `readyState === HAVE_NOTHING`.
	// For example, this can happen if a website resumes playback from where the user stopped watching it on
	// another occasion (e.g. Odysee). Or with streams. This is mostly to ensure that we don't attach to
	// an element until its `currentSrc` is set to check if it cross-origin or not.
	// If this happens, we'll attach to it later, on a 'play' event.
	&& el.readyState >= HTMLMediaElement.HAVE_CURRENT_DATA
	) {
	this.esnureAttachToElement(el);
	break;
	}
	}
	}

[VimalMollyn]

Oh that's a cool idea! Sorry, I haven't had the time to work on this but I think I may get some time After May 15th. Cheers :)

[WofWca]

I haven't made this clear. The reason I don't like "opening directly" 100% automatically is because it could get confusing. Because you open a link and then it automatically "opens directly" and you don't know whether the link was like this initially or it's the extension that did it.
Maybe there's a way to avoid this, then it would be cool.

Maybe some kind of notification, like "Automatically redirected from <original link>. <button>Go back</button> <button>Disable automatic redirects</button>". Need to make it immediately visible and not annoying though.