List Scrobbling bookmarklet

A few weeks ago, I introduced a bookmarklet that I’d created for Auto-scrobbling BBC Radio using the brilliant web app, Universal Scrobbler. Since then, I’ve been using the bookmarklet myself pretty regularly! It’s been very useful at work and so far I’ve not seen a bug (UI improvements maybe, but not actual bug!).

But there is still a problem, sometimes I don’t listen to the radio live, as it broadcasts. The BBC iPlayer is a brilliant service and I often use it to listen to shows that I would otherwise have missed altogether. But because there’s no live broadcast, there’s also no live track update. This means that, should I want to, I can’t scrobble the music I’m listening to! Looking on the feature requests on the web app’s forum, it’s been wished for in some form or another, by a majority of the community of users posting.

My newest bookmarklet sets out to solve this problem in part. For my specific scenario, I have solved it as much as I can with just the frontend to play with. It is now possible to go to the tracklisting of any BBC radio show, and get two batches of JSON code, one with all the artist names, the other with all the track names. This is very specific to the BBC website and the current layout they’re using, but that’s the instability that comes with bookmarklets which are relying on consistencies within the DOM.

The thing that may interest more people is the second half of the process, which happens on the Universal Scrobbler site itself. When the bookmarklet detects that it’s being run on the site, a box will appear with two text boxes to enter two batches of JSON code, this (if parsed correctly) will then allow for a batch scrobble operation to begin, using pre-existing features of the site.

It’s certainly not a perfect solution, but it’s pretty close. And it means that any JSON code can be entered into the two boxes, meaning playlist scrobbling is more of a possibility! Further to this, the bookmarklet is extendable, with the possibility of other sites being support to allow scrobbling from them as well!

As with the auto-scrobbling bookmark, I haven’t tested this. I know it won’t work on IE7 or below, there’s a few properties used for positioning of the UI that may not be supported in certain other browsers, but I’m not sure. Try it in a modern browser, and you should find it works! To get it, just click the link below and follow the simple instructions.

Universal Scrobbler :: List Scrobbler

Once you’ve done that, the bookmarklet works differently depending on where you are. If you’re on a BBC page, for a radio programme (I’d assume it’d work for ones that are live and updating their track listing as they go too!), clicking the bookmarklet will grab all the tracks it can find, show a white box in the middle of the page and give you the artist and track details in JSON code. If you’re on the Universal Scrobbler site, a similar white box will appear in the middle of the page and you can put JSON code into the two boxes it contains. When you click “Scrobble All”, it will visibly begin scrobbling (if it doesn’t something’s wrong!), once it’s finished, the box will disappear and you’ll see a confirmation message.

Hopefully something here will be useful for someone else to enjoy too!

Useful Links

 Universal Scrobbler

 Universal Scrobbler Last.Fm group page

 Universal Scrobbler’s creator on Last.Fm, OnDistantShores

Javascript: Selecting a range of checkboxes

A quick post about a small snippet of code that I’ve quickly written up, just to see how easily it could be done. It’s a feature that I feel should be on every web app (there are exceptions though). It’s the ability, when dealing with a list of checkboxes (in an email client for example), to be able to select one checkbox and then, while holding shift, select another and for this to then select all those checkboxes in between. To effectively select a range of checkboxes all at once.

This reduces the number of clicks required, in some cases, drastically and is one of those nice little touches which really makes you feel as though the user interaction with a web app has been considered. To make things even better, it’s a very simple feature to implement! I’ve attempted to do it sparingly, but I’m sure it can be condensed even more. And my comments can of course be removed to save space.

Hopefully this will help someone  to add a nice little extra to their web app, just as a final bit of polish. I’ve put it on to Codepen, which means if I’ve made a massive error, someone can fork me and correct it!

You can find my code at and it includes a demo of the code working, do try it out! It may be something that’s helpful to you!

Auto-Scrobbling bookmarklet

I’ve recently got back into the habit of using Last.Fm (again!) and scrobbling whatever I’m listening to, to it. This has been fine for the most part, I use either Spotify or iTunes to listen to my music and both of these having scrobbling features, I also occasionally listen to Last.FM radio, which of course has scrobbling as part of it.

The last thing that I couldn’t work out, was scrobbling the music played on the radio. I’m a big fan of BBC 6Music, it’s a brilliant station, great for when you’re at work and you really shouldn’t be mucking about with choosing music too much and there’s rarely a track that I’m embarrassed to say I’ve listened to.

However, there is very little provision for scrobbling radio stations, it’s generally very platform specific. One website has the answer however, Universal Scrobbler will fetch the track listings from several locations, a few of which, are BBC radio stations. Meaning I can fetch the latest tracks played on 6Music and scrobble the ones I’ve listened to.

There’s one last problem however, I still have to regularly go back to the website to fetch in the new tracks being played and scrobble those. This can be a pain, and when you’re at work, you probably shouldn’t be mucking about with this if you don’t have the time to muck around with your own music! So in a few minutes, I got to grips with the website and created a bookmarklet for the site.

Continue reading Auto-Scrobbling bookmarklet

Javascript: addEventListener and element.event

A quick post on the differences between addEventListener and element.event.

addEventListener and element.event, on first appearances, do the same thing. They allow a custom function or action to be linked to a javascript event, which are usually triggered by user-input.

But in more detail they do in fact have differences and for this reason, they should be used and treated differently. Each case where either is required should be assessed to make sure that it’s the best option of the two.

Using both methods

To use an addEventListener for the mousedown event, for example, we would do this.

var mouseInput = function(e) {
//filter the mouse inputs you're looking for
//do something based on the mouse input

document.addEventListener('mousedown', mouseInput, true);

The alternative element.event method would look like this.

var mouseInput = function(e) {
//filter the mouse inputs you're looking for
//do something based on the mouse input

document.onmousedown = mouseInput;

That’s it, and in most cases, both those will do the same thing…

The Exception to Explain the Difference

However, the methods are actually doing different things behind the things.


addEventListener assigns an additional function or action to carry out when the event happens. The clue is in the name really, addEventListener suggests that it won’t overwrite or override any other actions. This is generally a good thing, scripts, extensions and the browser itself will have assigned things to certain events and it may make the User Experience (UX) poorer if those normal functions and actions don’t happen when those specific events happen.

However, it also means that if you are purposely trying to change default actions to in fact improve the UX, this method won’t work “out-of-the-box”. An example of this is if you’re writing a web app and you want to force your own right click context menu*. You won’t surpress the context menu by default.

*A note on this idea: This is something you should carefully think about, it can certainly be useful, but many core browser operations can be found in the default right-click menu, and many extensions place a menu item to enable them to work effectively. It’s best to only use it on certain parts of the web page/app if you really are going to do this. It is very inadvisable to use this technique to stop people copying your content, there are other ways to take your content and it will often detriment genuine, non-malicious users.


element.event is an absolute assignment, it scraps and effectively destroys anything that was meant to happen when that event occurred and instead replaces it with yours. When put like that, it’s a pretty selfish way of coding as, again, it is likely to detriment the overal UX. Posts about making element.event assignments less problematic were commonly seen around a decade ago. But as addEventListener has become more supported over the years (it has been in the w3 spec for years and had support in Netscape 6(!), but only gained full support across the browsers when IE9 came in), and full featured libraries such as jQuery it has been less of an issue.

However, element.event has it’s place. It has much wider support. It’s likely that you’ll be able to support browser versions you’ve not even considered because this method of registering event listeners has been around since the beginning of Javascript (it’s fully supported in Netscape 2 as part of DOM 0…). So if compatibility is a real issue further than it is for most projects, and you can’t use a library (which will more than likely have this support built in), then this is your method to go for.

It also is quicker, and in some respects, a little easier to read, so if you’re writing a proof of concept or a quick script, where you know you won’t be interfering with anything unintentionally. Then this is also the method to choose.

The Best of Both

It is now accepted that using addEventListener over element.event is generally a better way to do things. You won’t be mucking about with the pre-assigned functions and actions for that event, which means that you’ll provide a better, more consistent UX overall.

However, if you actually are looking to surpress default actions using addEventListener, it is possible. This final example demonstrates how.

var mouseInput = function(e) {
//filter the mouse inputs you're looking for
//do something based on the mouse input

document.addEventListener('mousedown', mouseInput, true);

It should be noted that this example is actually a very bad idea if implemented, as it will stop any pre-assigned click functions. If you were trying to prevent the default context menu from appearing on right click, you should replace mousedown with contextmenu to do this correctly. See my (*) about this above.

Further Reading

 StackOverflow thread that brought these differences to my attention
 Further information on element.event registration
 Article from 2004 on making a cross-browser addEventListener (for the onload event) function for full browser support
 Article from 2001 about how difficult it was to code cross-browser event handlers (not much has changed sadly…)
 Mozilla Developer Network page on both event registration methods
 QuirksMode article on DOM Level 0 (the first version of DOM, used in the first iterations of Javascript)