Small PR for Error Feedback using Alert

[benyaminl]

Hello @woodruffw, I hope this help a little, I tried to implement the error feedback, so people can see the terminal output in alert() on respected page, I hope it simplify the option as I don't think we need notification permission (?) because as far as the user on the page, it will see the alert, just as far as the user doesn't dismiss it.

--no-terminal flag as no effect on windows, so I dismiss it, as https://github.com/yt-dlp/yt-dlp return error doesn't shown on pOut (stdout), when this flags on, so I hope this doesn't affect Linux or *nix/Darwin/macOS box (hopefully)

This method employ https://docs.python.org/3/library/subprocess.html#subprocess.Popen.communicate

Related to #40

Note : I only test this on Windows 10 21H2 for now, with Python 3.8 (as Python 3.6, 3.7 failed to run, so best to assume 3.8 is the minimum requirement). I will tried to test on my Linux box next week on Office.

Example :

[woodruffw]

Thanks for the PR. However, I'm inclined to pass on this, sorry. My reasoning:

• Most users find alert() dialogs distracting and frustrating (they suspend the entire page rather than just supplying information, which punishes users who accidentally attempt to play a URL.) The correct solution is some sort of non-blocking notification, but that requires extra browser permissions as you've noted.

• The logs from MPV and youtube-dl are themselves not useful in most cases: ff2mpv's two behavioral cases are "plays the link" and "doesn't play the link." The extension doesn't care about the underlying "why." In the worst case, providing logs like this encourages users to submit MPV and youtube-dl to this project rather than their respective upstreams, which creates more maintenance work for me and increases the number of links in the debugging chain.

• It introduces additional error states: these changes assume that the standard streams produced by MPV are UTF-8 formatted, which isn't guaranteed anywhere (MPV could spit out a filename encoded as UCS-2, for example, or just decide to print garbage). It also assumes that punting a potentially arbitrarily large-sized log to alert() won't be rejected by the browser as spam-like behavior, and won't get the extension flagged by Mozilla (I don't think the latter is likely, but I wouldn't blame them if they did.)

TL;DR: This feature is too invasive and brittle for the functionality that it introduces. If you want notifications, I suggest modifying your local copy of the native client (ff2mpv or ff2mpv.py) to include code that produces a native notification. That's what I have locally, and it looks like this (in Ruby):

require "json"

len = STDIN.read(4).unpack1("L")
data = JSON.parse(STDIN.read(len))
url = data["url"]

args = %w[--no-terminal]

system "notify-send", "ff2mpv", url
pid = spawn "mpv", *args, "--", url, in: :close, out: "/dev/null", err: "/dev/null"

Process.detach pid

[benyaminl]

@woodruffw Will you receive it if I change it to Firefox Notification? I think it's not hard, just I'm experimenting with this. Or you intend to implement error on Python or Ruby side code, like you have done before on your own script, as Python has notify2/py-notifier, well we can also use msgbox from vbs or windows 10 notification.

[woodruffw]

Will you receive it if I change it to Firefox Notification?

Not at this time, no, sorry. I'd still prefer to keep the extension's permissions to a bare minimum.

At this time, I'd prefer it if individual users made changes to their local copies of the native client to accommodate their own notification needs. My justification there is that cross-platform notifications are hard to do without introducing dependencies, which in turn makes it harder for novice users to correctly install the extension and client correctly. And harder installation means more issues, maintenance burden, etc.