joeytwiddle Author

Sorry, only seeing this now.

That's a long page! I'm not sure what would fix it. And I don't have Safari to test on.

But if you find any code you can add to this script, to make it work, I will happily add it to the script!

It looks to me like the News tab on Google is adding favicons by itself.

Therefore this userscript doesn't need to add them.

Hopefully this is now fixed in version 1.8.1

This can be done with a little extra CSS:

    // When YouTube is fullscreen, hide the buttons
    s+=' .play_btn { display: none; }';

It looks like that might also work on other sites, if they use the same CSS class.

Sorry for the slow reply, I was making a cup of tea.

For the moment we are using the service at but I have noted down your services, and we could add them as fallbacks for the future.

The new version uses GM_xmlhttpRequest() on Ecosia and StartPage, to work around CSP.

If this works well enough, we could actually use that as the default (initial) way for all

In the latest version, the styling has been minimalised to a simple dashed underline for related links.

Styling is controlled by three variables in the script:

  • thisLinkHighlightStyle
  • highlightStyle
  • visitingStyle

The original settings are commented out, if anyone wants to restore them.

Thanks Marti, I did adopt your solution in the end.

Sorry I didn't see your message earlier. I would love email notification for this site. ;)

Is it possible you were using FaviconizeTheWeb instead of FaviconizeGoogle? It is a secret feature of that script to make random icons appear in unexpected places!

If you are still getting this problem with FaviconizeGoogle, please send me a screenshot so I can reproduce and investigate. Cheers.

Sorry for late reply lol.

You can set the last value to 0.0 to make it transparent:


Or you can just replace the whole string:


However I must admit my implementation was not so beautiful. If the link currently has element styling, then the script will override that element styling. (That means the site's CSS is also not so beautiful!)

If I was writing it again, I would use a CSS class with !important, and leave the untouched.

Re: @joeytwiddle:

By the way, I just added @grant GM_addStyle not because we are using it, but because @grant none and @require were resulting in a massive freezeup during page load on Firefox + Greasemonkey.

Re: @joeytwiddle:

This site knows where the userscript is on Github, because it auto-updates from there. It would be nice if the site could make that upstream URL available, e.g. on the SourceCode page.

Thanks for that. Sorry I didn't see it until now!

You cannot imagine how long I spent fiddling with the border-radius on the original script. In the end my eyes melted and I went large, possibly encouraged by iPhone marketing material which was prevalent at that time.

But it appears to be 2 vs 1 in here, so I have merged your styles into my copy. :)

And I have just done an update to @require jQuery, because $ appears to be missing from today.

Just thinking about the license ... imagine if we wanted to actually take our script and use it on their site. What license would make them able to do that?

My userscripts are hidden deep inside a monolithic repo: One day I may get organised like jerone and separate them out.


I often don't see the feature when creating a new issue.

I think this might be because Github is using pushState() to make a single-page-app, so the script is not loaded because the @includes were checked when I was viewing an earlier page.

If that is the cause, then I suppose the workaround would be to @include the script on all Github pages, and decide whether to activate the script more dynamically (e.g. just after a pushState() occurs).

Might be a bit of a fiddle, but it's probably something that a few other userscripts are needing to do these days.

This script looked useful so I gave it a go, but when I visited it kept reloading the page!

I saw the filter list appear. But then the reload started. I haven't had time to debug the cause. I could take a look in a week or two...

I'm using Chrome 36 with TamperMonkey on Mac OSX, which usually seems to do a good job with Greasemonkey compatibility, but I suspect the different environment is the cause. (I understand you're using Firefox.)

Disabling Ghostery and AdBlock extensions did not help.

Re: @jerone:

Gosh it's only been 9 days since the last set of fixes! I've updated the script and it looks ok to me now (Chrome).

Thanks, will do the screenshot thing.

Thanks both, I have now updated all my active scripts with @grant and @version tags. (I notice @grant none is no longer needed since GM 2.0, but it is still useful for legacy users, and to indicate that the script has been vetted.)

Regarding the tag listings on the /add/scripts page, I don't think @description is OUJS-specific! Since that is listed, I think we could also list @version and recommend authors to fill that in too. Although I will have to get into the habit of incrementing that ... I wonder if I should make a git hook. Or perhaps it could be a feature of this site, to auto increment @version when the author uploads or pushes a new version!

Re: @Marti:

Greasemonkey is awesome but.

What is the point of the sandbox? To protect site scripts from using Greasemonkey's GM_xmlHttpRequest and GM_getValue. But at what cost?

90% of scripts don't even need those functions, and could safely run in page scope. Yet they have to deal with the excessively limiting sandbox in order to run, which manages to interfere with even the most trivial things like event handler callbacks.

Sure you can workaround these limitations with .wrappedObject or just break the security with unsafeWindow when you get desperate. But working this way means your script now cannot work without a Firefox Greasemonkey environment. It will break in Chrome and it won't run as a normal script or as a bookmarklet. I prefer to write portable code!

I recall having to change my script three times in a row because each new Greasemonkey release changed the workarounds I had to do to deal with the sandbox. Yes, occasionally GM_XHR and GM_set/getValue are awesome features, but only in 10% of the scripts. The rest of the time it's just an uphill struggle for no great benefit.

Anyway I'm glad to see that nowadays if we don't use any GM_ functions we can run outside the sandbox. But still it's a shame to be sandboxed when I just want to use GM_addStyle.

Anyway just wanted to get that off my chest!


DRY is Don't Repeat Yourself. Although it doesn't exactly apply here, I just notice that with the issues feature and collaboration this site is solving problems we already have a solution for. I would say "we should encourage people to get onto GitHub" because it is an awesome place for collaborative development, but the fact it is a non-free platform gives me pause. I am very glad to see OpenUserJS is a GNU project from the outset! :) Anyway no problem, we can collaborate on Github or on here, so it seems we have the best of both worlds!

Syncing changes?

But I am concerned if a collaborator contributes to a script on here, I might not notice the changes, and end up clobbering it with a small update and a push to Github. If your changes were complex ... well diff and patch I guess! :P I notice there is no "script history" here at the moment. (That is quite a useful feature on USO which might dissuade help malicious users from injecting evil stuff into their script before uploading a clean version.)

Minimum Meta Tags

My suggestion is that meta-tags which you think are really important could go in a section just above the " Specific" block. I only suggest it because I didn't have time to click and read the links when I was uploading. There are quite a few more tags than when I last looked. The links are good!

After this long post, you had better like my userscript!

I wrote GrimeApe a while back, which is how I learned that synchronous XHRs are bad! That had no security concerns. By which I mean, it had no concern for security! :D I always meant to rewrite it in Node but never did... it could have gone the way of TOMODO had I done it right.

Anyway, Greasemonkey, TamperMonkey and userscripts rock. Down with GM_*!

Re: @joeytwiddle:

After reinstalling the script and restarting Firefox again, it has now stopped working. THANKS A LOT MARTI!

Chromium indicates that it got $ from the CDN:

> window.$
function (t,e){return new Q.fn.init(t,e)}               frameworks-df9e4beac80276ed3dfa56be0d97b536d0f5ee12.js:2

Don't ask Firefox's Browser Console (Ctrl-Shift-J) about window.$, it will say undefined. Ask the Web Console instead (Ctrl-Shift-K), it will say [object Function]. But you still need the first one open to see all the error messages...

I can get somewhere in Greasemonkey by putting this at the top of my script:

var $ = unsafeWindow.$;

But then I get "Permission denied to access property 'handler'". The problem appears to be GreaseMonkey's long-problematic security enhancements. These make scripting a nightmare, especially since 90% of scripts run in page-scope, and don't need any special access. But it seems if I remove the @grant GM_addStyle then it seems the security locks turn off. So I did that.

Please give the latest version a try!

I thought I would use jQuery to save time. Of course I had forgotten about Greasemonkey ... :P

After updating to the latest Greasemonkey (nightly 2014-06-23), this userscript is still running fine for me. I got $ and everything! So what's the beef, cowboy?