MusicBrainz Magic Tagger Button is a browser user script that aims to simplify the handling of the green tagger button that is shown on MusicBrainz sites to load a release or recording into Picard.
If you load a MusicBrainz release or recording page in your browser while Picard is running, it will automatically activate the tagger integration and enable the green tagger buttons
If you click a green tagger button, it will change the button’s icon to indicate whether the release or recording could be sent to Picard or whether there was an error .
This is a user script that you install in your browser using a user script manager such as Greasemonkey, Violentmonkey or Tampermonkey. Please see the Github page for details on how to use this:
Please note:
You should use Picard 2.6 Beta 2 or later. For earlier versions of Picard this will not work in most browsers (except for Firefox)
You should use a current version of a reasonable modern browser. This has been tested on latest versions of Firefox, Google Chrome, Microsoft Edge, Opera and Vivaldi using Greasemonkey, Violentmonkey and Tampermonkey. Other browsers might not be supported
In particular Apple Safari is not supportedUPDATE: See below for Safari support
It is recommended that you use the default configuration for the browser integration in Picard. That means the “Default listening port” in Options > Advanced > Network > Browser integration should be set to 8000. At the very minimum it must be set to a value between 8000 and 8010.
I have updated the script to fix some issues with import scripts. Basically the Magic Tagger Button script triggered a reload of the add release page, breaking import script such as the Discogs importer.
This has been fixed, the Magic Tagger Button now is excluded from the add release pages.
The script got a few more updates recently, current version is 0.5.11. Changes:
Collection and series pages are supported
Tagger port detection now works much better on Windows. Previously if Picard was not listening on the port each request to probe the port took 2 seconds. That meant if Picard was not running it took the script 20 seconds to figure that out. Now the requests time out much faster, making this plugin more convenient to use.
It will be a very strange day when I do a reinstall and wonder where all the tagger buttons went. Any chance of having this integrated into MB proper? Or are there still outliers which mean it’s not possible?
I’m personally not sure whether we want this to be integrated into the MB main site. At least not by default. Maybe for logged in users who have explicitly enabled this option.
In order to figure out if Picard is listening locally the script makes a call to local addresses for ports between 8000 and 8010. So it does issue one HTTP request each for http://127.0.0.1:8000 up to http://127.0.0.1:8010 . And if it does not find Picard running it does this on every page on MB that potentially can contain a tagger button.
On most people’s computers nothing is running there. But for whatever reason one might have a local web server running on one of those ports, and having this getting hit constantly while browsing musicbrainz.org is not really nice. In the worst case this might even have unwanted side effects. This is best a functionality the user knowingly enables.
It also does not run on every browser. For example there is currently no way to have this work on Safari. Of course the website could just fall back to the current behavior there.
However, integrating this properly into MB server would have some advantages. Especially the server could be changed in a way that allows enabling the tagger button without the page reload that is currently necessary. It would also allow for example for the user to configure the port range to check, which would reduce the impact of the port scan issue.
An update for users of Safari on macOS: With the latest version 0.7 you can get the Magic Tagger Button also in Safari, if you use the latest 4.x beta of the Userscripts extension.
The Userscripts 4.x beta is currently only available after registration (see the link above), but it looks like the final release will be out soon. It will be only available for macOS 11.0 or later, though.
UPDATE: Userscripts version 4 for Safari is now available
Thanks for the info. Yes, that should affect the plugin. I’ll look into it. Not yet clear to me whether this requires code changes or it will just automatically show a notification when the request is triggered.
Overall I think this is change is a good thing. Access to local network from any website can be harmful.
I experimented with this. Actually it will not affect the user script directly for now. Requests by plugins seem to be excluded, and the userscript is using the GM.xmlHttpRequest interface provided by the user script manager plugin. So everything works as before.
If the userscript would use the normal browser provided XMLHttpRequest (which the Magic Tagger Button script does should GM.xmlHttpRequest not be provided by the user script plugin) then the restriction would trigger. The browser in this case will show a notification to the user that the website wants to access local resources.
One downside is that if the user allows this the already attempted requests have already failed. But the setting is remembered for the website and if allowed the requests will work then on the next page load.