Register protocol handler in WebUI for magnet links

[CoryG89]

Background

As far as I know, currently adding magnet links for download in the WebUI means copying and pasting the magnet link manually. This PR adds some code to register the WebUI as a handler for magnet links. I just looked and apparently an issue was opened for this at #945, but was never implemented. This seemed easy enough to do so I did it and am currently using it via the alternative WebUI feature.

Changes

• Modified client.js to call navigator.registerProtocolHandler, allowing the WebUI to be registered as a handler for magnet links. As I have coded it, magnet links will open the WebUI and encode the magnet link into a query parameter named "magnet".
• Also added some logic to check for the "magnet" query parameter, and if present open the download page with the magnet url.

MDN documentation for navigator.registerProtocolHandler: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler

To enable the WebUI to handle magnet links, the user must authorize it manually. In Google Chrome, this can be done by clicking on the "handler" icon in the browser's address bar.

After doing this, when the user clicks on a magnet link in the browser, the WebUI will be opened and the "add torrrent link" dialog will be automatically opened with the magnet link already added.

Screenshot

[CoryG89]

@Chocobo1 Made the following changes:

• Eliminated the use of newer browser features such as URLSearchParams
• Now checking to make sure navigator.registerProtocolHandler is defined as a function before trying to call it.
• Added code in onClose of the download window to remove the magnet uri from the WebUI url when the download window is closed. If it is not removed and the user refreshes, the download window will keep popping up, even if they have already added the torrent as a download.
• I'm now passing the param in the URI hash rather than in the query string. I think I would prefer it in the hash, but I can revert this change to use the query string if desired.

[CoryG89]

I tried testing in IE11, but it seems that I am having some trouble getting IE11 to run properly on my system even before my changes. The torrent list doesn't seem to show up for me in IE11. I am seeing no erros in the console with these changes though.

[CoryG89]

@Chocobo1 Updated based on your feedback.

[CoryG89]

I realized that there is really no need to wait for onClose to remove the download param from the URL, so I made that change as well. The download param is now removed from the WebUI url immediately, just before the extracted torrent uri is passed to the download page.

[Chocobo1]

The rest LGTM.
Also you need to squash all the commits into the first one before I can approve & merge.

[CoryG89]

Combined lines and squashed commits.

[Chocobo1]

Thank you!

[bitingsock]

Is it possible to have it not prompt for options and just start downloading and additionally close it's window. So you would click on a link and it would just start without further UI

[CoryG89]

I'm sure it's possible, though I doubt that would be desired by everyone such that it should be the default behavior.

Probably better as a feature request to add an option for automatically starting magnet links. Would be similar to the option that currently exists for watching a directory for torrent files and automatically adding those.

[BeecherNetworks]

I'm getting the error "Your browser does not support this feature" in Firefox.

[CoryG89]

Hmm, I know this was tested as working in Firefox when it was implemented:

Taking a look at the recent revision history for the navigator.registerProtocolHandler API on MDN:

https://wiki.developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler$compare?locale=en-US&from=1585417&to=1563901

It looks like browsers may have tightened security around this API recently, it looks like specifically requiring a secure context (HTTPS, valid SSL certificate). Depending on the changes they made the typeof check we currently have may not be sufficient to catch the error.

@BeecherNetworks Did this error break any functionality, or was it just being logged to the JS/devtools console? Also do you happen to know whether this error was observed over HTTP or HTTPS?

To avoid the error, it may now be necessary to add code to check for https before attempting to register a protocol handler.

[CoryG89]

It was working in at least both Chrome and Firefox previously, later when I'm home I'll test both of those, with and without SSL to determine the current status.

[BeecherNetworks]

This is on HTTP. I'll put Nginx in front of it tomorrow with a cert to check.

[ldexterldesign]

FYI #11229 (comment)