Thanks to your persistence I just tweaked just about every knob there is to tweak and discovered this: once the following preferences are set and Firefox is restarted, the issue appears.

user_pref("extensions.autohidestatusbar.alwayshide", true);
user_pref("extensions.autohidestatusbar.showondownload", false);
user_pref("extensions.autohidestatusbar.showonpageload", false);
user_pref("extensions.autohidestatusbar.showstatusbaritem", false);
user_pref("extensions.autohidestatusbar.timer", 300);
user_pref("extensions.autohidestatusbar.usePanel", true);

(I hope this gets formatted correctly.)

There are two traps here as far as I can see. The first is that once .alwayshide is set to true (i.e. ”Always hide” is selected in aHS’ preferences), the state of .usePanel can’t be changed through the GUI (”Floating statusbar”), and yet, it does make a difference. So it has to be unset before ”Always hide” is selected. Apparently a defect in the add-on’s design, though I see why it might make sense, were it not for the issue at hand (which is a defect unto its own).

The other trap is that the issue of script installing links doing nothing (as described above) doesn’t manifest itself until Firefox is restarted. So to see it you have to turn on ”Floating statusbar”, then (possibly) ”Always hide”, then restart Firefox and boom: Install links have stopped working.

There’s still a chance this might not be the case for you: I’m running Firefox from the distro repositories on Ubuntu 10.04, and Greasemonkey on this setup also comes from the repos. So if you still can’t reproduce this, you may be running the newer version of GM (0.8.20100211.5-1ubuntu2 here, with 0.8.20100408.6 being the latest release on addons.mozilla.org).

It’s a symbolic link. I tried moving the actual .mozilla back into ~, but it made no difference (i.e. the Install link still wouldn’t work). FWIW, when ran from a terminal, Firefox prints

shouldload: http://userscripts.org/scripts/source/31864.user.js"
ignorescript: false

when I click the Install link with autoHideStatusbar running. It’s the same it does when autoHideStatusbar is disabled, but with the latter, it also prints ”ignoring next script…” and then the installation pop-up appears as it should.

Don’t worry too much about fixing this, I install scripts rarely enough that working around this by disabling autoHideStatusbar each time isn’t too much of a hassle. Although of course, if a solution is found, I’m all the happier.

(And I’m sorry, ky_bluegrass, for hijacking your thread.)

Actually, I do have .mozilla (containing the FF profiles) symlinked. Anything else therein, such as gm_scripts, isn’t though.

According to dates Greasemonkey was installed first, autoHideStatusbar later.

Funnily, I can’t reproduce the issue myself on another installation, but on my home desktop it’s 100 % reproductible: I can’t install scripts until I disable autoHideStatusbar. Maybe the discrepancy means the incompatibility is actually between autoHideStatusbar and another plugin.

Marti: I’m not sure of the installation order. How can I find it out?

For me, the same symptoms were caused by apparent incompatibility btw Greasemonkey and another add-on, autoHideStatusbar, so you could try disabling other add-ons.

Hi Florence!

I followed your instructions and indeed, login now again works perfectly. I won’t touch the Facebook links from now on. :)

Thanks for responding, and for your help!

Two out of three times when trying to log in to Anobii (using Firefox 3.6.6.) I get redirected to Facebook and remain unlogged-in to Anobii. That is, even if I return to Anobii from Facebook (where I didn’t want to go), I’m still not logged in.

I get sent to Facebook even if I uncheck the Facebook option on the login page. The only times I can get in to Anobii are when the Facebook option for some reason doesn’t even appear on the login page, usually only after two or three times of being wrongly forwarded to Facebook.

Possibly the worst part is that I’ve not even connected my Anobii account to my Facebook account. I don’t want the two linked together, and still the login fails badly due to this Facebook hassle.

Spoke too soon I see: the ’fix’ I linked to only fixed this for logged in users (whose comments didn’t have proper paragraphing either, on my site).

A fix for this has been posted in MCEComments’ author’s blog’s comments: set ’force_p_newlines’ to true and ’force_br_newlines’ to false in the plugin code. In v0.4.8 they’re on lines 268-269 of tinyMCEComments.php.