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

Clicking on Magnet links doesn't do anything after 0.10.0 #911

Closed
djgenesis opened this issue Sep 7, 2016 · 11 comments
Closed

Clicking on Magnet links doesn't do anything after 0.10.0 #911

djgenesis opened this issue Sep 7, 2016 · 11 comments
Milestone

Comments

@djgenesis
Copy link

What version of WebTorrent Desktop? (See the 'About WebTorrent' menu)
0.11.0 and above
What operating system and version?
Windows 10 Pro
What did you do?
Click a magnet link in any website.
What did you expect to happen?
Open it in Webtorrent Desktop
What actually happened?
Nothing

Until version 0.10.0 I clicked on magnet links and it opened just fine. I have tried:
-ALL versions after 0.10.0 -> 11.12.13.13.1 & 14
-All 3 browsers (Firefox, Chrome, MEdge)
-both without making it the default torrent app and with making it
-3 devices. 2 laptops and a media box. All with windows 10
and none of these combinations opens a magnet link. I am no programmer but since 0.10.0 still works fine clicking on any magnet link I am guessing that there is something going on with 0.11.0 new feature of "New Preference to "Set WebTorrent as default handler for torrents and magnet links"". I am looking through the issues and there is no mention on this. Hey... I cant be the only one :)

Hope you figure this out cause I am stuck to v0.10.0 for ever.

@djgenesis
Copy link
Author

The only solution I found so far is through Firefox to set the default handler for magnet links inside Firefox settings to Webtorrent Desktop.

@Goldob
Copy link
Contributor

Goldob commented Sep 7, 2016

This is intentional. Some users found it intrusive for WebTorrent to automatically set itself as default magnet and torrent file handler. Try setting WebTorrent as default torrent app in Edit > Preferences menu.

See #771 for more details.

@djgenesis
Copy link
Author

As I mentioned above, I already did. I tried every combination with settings, browsers and WTD versions. Any version above 0.10.0 doesnt grab the magnet links. I have also checked all the issues. Am I the only one with this problem? Strange cause I tried the same things on 2 laptops, 1 tablet and one Media Box all on windows 10. If there is any more info logs etc I can provide, let me know.

@anonymlol
Copy link
Contributor

Same issue as #791 I assume.

@djgenesis
Copy link
Author

Yes. I also confirm that the problem exists in all versions after 0.10.0. Both fresh installs (after uninstallation) and upgrades from previous versions.

@dcposch dcposch added this to the v0.14 milestone Sep 9, 2016
@dcposch
Copy link
Contributor

dcposch commented Sep 13, 2016

@djgenesis thanks for being so thorough. We'll try to fix this in the next release

@dcposch dcposch added the bug label Sep 13, 2016
@djgenesis
Copy link
Author

Happy to help guys. Keep up the great work.

@dcposch dcposch modified the milestones: v0.16, v0.14 Sep 16, 2016
@djgenesis
Copy link
Author

Installed v0.15 on one of my laptops and now the problem is fixed on all browsers (Chrome, Edge, Firefox) !!! On Firefox you just need to "unassociate" magnets with webtorrent and then when it asks you what to do, you just have to "reassociate". So the problem was in versions between 0.10 and 0.15. I will try it on all the devices once again to see if all are grabing the magnet links

@dcposch
Copy link
Contributor

dcposch commented Sep 16, 2016

@djgenesis wow, sweet. I didn't think we had fixed it yet.

There were def other bugfixes in 0.15, so maybe one of them indirectly made the magnet link handler work again.

@pepjo
Copy link

pepjo commented Sep 23, 2016

I'm at 0.16 and still does not work :/

bnjmnt4n added a commit that referenced this issue Oct 2, 2016
…ating.

Previously, they were only installed when the preference was changed.
This caused the handlers to point to non-existing files after updates
occurred and older versions were removed by Squirrel.

Closes #791, #911.
bnjmnt4n added a commit that referenced this issue Oct 3, 2016
…ating.

Previously, they were only installed when the preference was changed.
This caused the handlers to point to non-existing files after updates
occurred and older versions were removed by Squirrel.

Closes #791, #911.
@feross feross modified the milestones: v1.0, v0.17 Oct 5, 2016
bnjmnt4n added a commit that referenced this issue Oct 6, 2016
…ating.

Previously, they were only installed when the preference was changed.
This caused the handlers to point to non-existing files after updates
occurred and older versions were removed by Squirrel.

Closes #791, #911.
mathiasvr pushed a commit that referenced this issue Sep 26, 2018
* Ensure that default file/protocol handlers are re-installed after updating.

Previously, they were only installed when the preference was changed.
This caused the handlers to point to non-existing files after updates
occurred and older versions were removed by Squirrel.

Closes #791, #911.

* #1340: Switch to async metadata updates.

* Use fat arrow

* Fix issue track number not displayed if total number of tracks is not defined (common.track.of === null).

* Add disk number in addition to track number.

* Update order of audio properties from: album, track, disk, format to track, disk, album, format

* #1340 Update music-metadata to 2.5.0, enabling async 'per' tag updates
#1452 Fix for playing some '.m4b' files

* #1340 Commented out the metadata event debug output.

* #1340 Remove line comment to get rid of max line length lint error

* Update music-metadata 2.6.0 to fix some async events are getting triggered.

* Return JSX block.

* Get rid of third parameter which is replaced by CSS capitalize

* Fixed error when value is undefined.

* Update music-metadata dependency to 2.6.1.

* fix(package): update music-metadata to version 3.1.0

Closes #1478

* Revert "Ensure that default file/protocol handlers are re-installed after updating."

This reverts commit 39145b2.
DiegoRBaquero pushed a commit that referenced this issue Sep 23, 2021
…ating. (#997)

Previously, they were only installed when the preference was changed.
This caused the handlers to point to non-existing files after updates
occurred and older versions were removed by Squirrel.

Closes #791, #911.
@github-actions
Copy link

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@github-actions github-actions bot added the stale label Oct 21, 2022
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants