This does not apply only to file:// URLs as in the original post, it applies regardless of URL. It does only happen in the grant none case.
I might have been too quick on the description above. Apparently it is indeed related to file://. I'm not sure what I screwed up the first time around. But:
Script whose entire contents is location.href = 'file://'; gives:
location.href = 'file://';
Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.href]
Source File: file:///.../test.user.js
And if I edit 'file://' to 'http://www.example.com/' then it works as expected. The same failure happens with .assign().
I've now gotten at least once:
Security Error: Content at http://localhost/ may not load or link to file:///.
But: http://jsbin.com/uditif/1/edit . Doing the same thing from a regular web page produces exactly the same result.
See http://www.greasespot.net/2012/09/the-design-of-greasemonkey-10.html -- we want user scripts to act like web pages. Mostly so that things work, but in this case it seems this particular thing doesn't work. Nevertheless, I think this is going to have to be Working As Intended. As mentioned in the mailing list thread, you can work around this by giving yourself any @grant to get legacy sandbox behavior if that's what you prefer.