I have disabled all those plugins and noticed a few months ago that Firefox sometimes re-enables those plugins automatically. When does it happen? I verified that plugins are automatically enabled whenever I switch Firefox versions. My main Firefox installation runs the latest Aurora build, but I have a stable version of Firefox installed on the same computer.

Yesterday I had to switch versions to check out Twitter’s implementation of Content Security Policy which has been only enabled for Firefox 4 versions and not the Aurora builds which are already listed as Firefox 5.

Today when I checked my plugins in Firefox 5 I noticed that they all had been re-enabled. To verify that the version switch was indeed the culprit I disabled all plugins again, closed Firefox 5, loaded and exited Firefox 4, and opened Firefox 5 again. The result? All previously disabled plugins were enabled again.

There may be additional circumstances where plugins are re-enabled automatically. Browser updates are one possibility. Please note that I have not verified this.

The core problem now is that there is no option available to users to block plugins from being installed in the browser. Well, that’s not entirely true but the controls are insufficient at best. See, you can disable plugin scanning, but this will remove already installed – and probably in use – plugins from the browser as well. So that is not really an option.

You can block some plugins either in the Windows Registry, if you use Windows, in the Firefox about:config configuration settings or by deleting plugins locally. All three methods have disadvantages.

Only some plugins can be blocked in the Registry by deleting their keys. While that’s nice and all, it is insufficient to resolve the issue with other plugins that still get re-enabled automatically. It is also likely that updates or new installations of programs that have added the plugins to the Registry in first place will re-add them there.

The Firefox about:config dialog holds options to block all plugin scans, or scans for Acrobat, QuickTime, SunJRE, and WindowsMediaPlayer. The latter can be blocked by changing the minimum version number requirement to a version that is not yet available, for instance 99. Look for plugin. scan.(Plugin-name) to find those plugins after entering about:config in the Firefox address bar. The description on the Mozilla help page seems to suggest that it is possible to add custom plugin names as a parameter, but that’s not explained anywhere on site.

Setting plugin.scan.plid.all to false blocks most plugin scans during startup of the browser.

Deleting plugins locally finally is an option, but those plugins are likely added again if the software that they are linked to is updated or re-installed. You can look-up the path of every active Firefox plugin by setting the parameter plugin.expose_full_path to true. The paths are then shown if you enter about:plugins in the Firefox address bar.

Your best bet currently is a mixture of all methods described above. But even if you manage to remove all plugins that you do not need, there is no guarantee that they won’t reappear later again.

Mozilla recently announced that they would make changes to the automatic integration of plugins in Firefox. This step is long overdue.

But the fear is only one side of the medal. Users who are careless about the installed plugins are benefiting immensely from the internal plugins. They personally do not have to follow the latest security announcements to update their plugins the second a new update is issued, Google does that for them.

Chrome users who prefer not to use the internal plugins can disable them easily.

The Chrome developers have added another powerful weapon to the web browser; Plugin controls that can be used to allow plugins only on whitelist domains, trusted domains that the user added to the browser.

The plugins will simply not work on other websites if configured correctly. That’s beneficial to users who need Flash or another plugin on a handful of sites only.

Google does not stop here, several interesting additions to Chrome’s plugin handling have been announced at the official Chromium Blog.

Google Chrome will protect the users from outdated plugins. It will simply refuse to run them and aid the user in updating the plugins so that they can be used again in the web browser. It is not clear how the plugin database will be maintained, it is however unlikely that all plugins available worldwide are listed in it. It is likely that the most popular plugins are maintained in the database.

Protection from out-of-date plug-ins: Medium-term, Google Chrome will start refusing to run certain out-of-date plug-ins (and help the user update).

A second interesting feature is the ability to warn users of plugins that have been infrequently used in the past. Some plugins are installed by software or the user and never used in the web browser. Chrome will warn the user about those plugins so that they can be deactivated in the plugin manager.

Warning before running infrequently used plug-ins: Some plug-ins are widely installed but typically not required for today’s Internet experience. For most users, any attempt to instantiate such a plug-in is suspicious and Google Chrome will warn on this condition

Those two additions can be very helpful and it is likely that other browser developers will offer those features in their browser eventually as well. Mozilla has already started to inform users about outdated plugins during updates.

The plugin check would analyse the plugins of the web browser and compare their version to the latest version offered by the plugin’s developer to inform the user if the plugin is up to date or needs updating.

This plugin check has now been extended by the developers to work with other web browsers as well making it a web tool for everyone who wants to verify that the installed plugins are up to date.

All that needs to be done to check the installed plugins is to visit the plugincheck website to do so.

The online service can identify many popular plugins. The plugin database is maintained by Mozilla and constantly expanded. It can however happen that some plugins are not recognized automatically by the service.

Three different statuses are available: Up To Date confirming that the latest version of the plugin is installed, Update suggesting that the plugin is outdated and Research if a plugin cannot be identified yet by the service.

Links lead either to the developer’s homepage or a Google search depending on the individual plugin’s status.

This is standard behavior in Mozilla Firefox, Opera and Google Chrome but not Microsoft’s Internet Explorer which as the only web browser of the four most popular ones support keyboard shortcuts on those websites.

Maybe you want to try it out for yourself. Visit Tuneglue, a music discovery service using Flash. If you work in the interface and the focus of the cursor is on the page then keyboard shortcuts are not working.

There are lots of threads by users about this problem which has been acknowledged by the developers but nothing has been done about it so far.

The only option users have at this point is to use the mouse to move the focus from the plugin to the web browser again which will make the keyboard shortcuts works again.

Has anyone else experienced this issue and would like to share their findings?

There are two main issues that come up with Firefox (one dealing with plugins and the other dealing with a “hidden” lock file). These two issues alone could be considered deal breakers with new users. As for plugins, I am going to show you how to install the Flashplayer plugin (as that is one of the most popular and widely used plugins) on Linux-based Firefox. So, without further adieu, let’s see how to get past these issues. The solutions are very simple.

Plugins

I have seen Firefox behave two ways: I have seen the browser automatically install the necessary plugins, and I have seen it demand manual installation of plugins. I would like to think the automated installation is where Linux Firefox is heading, but you can never count on automation 100% of the time. For those times when you will need to install Flashplayer manually here is how you do it.

The first thing you need to do is to download the appropriate version of the Flashplayer plugin. You can get the plugin from the Adobe Flashplayer Download Page. For simplicity sake download the source file which will be a tar.gz file. Once that is downloaded unpack the file with the command:

tar xvzf install_flash_player_10_linux.tar.gz

which will create the new directory install_flash_player_10_linux/. Change into that directory with the command:

cd install_flash_player_10_linux/

and you will find two files:

• flashplayer-installer
• libflashplayer.so

The file flashplayer-installer is the executable installer. In order to actually execute this you will have to give the file executable permissions with the command chmod u+x flashplayer-installer. Once you  have done this close your browser and issue the command ./flashplayer-installer. To complete the installation answer a few simple questions. Once the installer finishes, fire up Firefox and enter about:plugins in the address bar to check to make sure the plugin was installed. If all went well you should see a listing for Shockwave Flash.

Lock File

That dastardly lock file can be a real pain some times. When Firefox is running it creates a special file called a lock file in the users Firefox directory. As long as this lock file is there another instance of Firefox will not open. If Firefox crashes and the lock file isn’t automatically removed by Firefox, you will get an error message saying you need to close Firefox before it will run. There are two ways to do this. You can issue the command killall -9 firefox-bin and hope it takes the lock file with it, or you can remove the lock file manually.

To remove the file manually open up a terminal window and issue the command cd ~/.mozilla/firefox. Within this directory will be a directory unique to the user. To find out the name of this directory issue the command ls. The directory will be a random string of characters. Mine, for example, is u6n8y834.default. Change into this directory and issue the command ls. You should now see a file called lock. Issue the command rm lock to remove this file. Firefox should now start up.

The issue of this lock file shouldn’t come up very often. But when it does, it’s nice to know how to solve the problem.

Final Thoughts

Firefox is an outstanding browser. But no matter how good it is, it can still have issues. When these issues arise, it is reassuring to know you can get beyond them. Hopefully, however, your experience with Firefox in Linux will be bereft of problems.

Several important locations will be scanned in the process including running programs, browser plugins, winlogon notifications, browser helper objects, Internet Explorer toolbars or Windows Services. FreeFixer does not rate the findings which means that it is up to the user to perform further research to find out if they are dangerous or not. The software makes however use of a whitelist to remove system processes, services and other official files from the list of results to narrow down the result list to potentially dangerous ones.

Each item will be listed with its name and location, other relvant values depending on the type of item and options to lookup information about it on the Internet and to delete it.

Results can be saved in a log file for further processing. Selected items can be fixed (that means deleted) by clicking on the Fix button in the software. It is usually a good idea to perform a search on the Internet before deleting any files from the list. Some can be excluded just by looking at their names while some do not give the slightest hint at what they are.

Freefixer makes use of a database that is located on the developers website which contains additional information about each item. One interesting aspect of the database is that it will display user actions by displaying a pie chart detailing how many users kept and removed the item from their computer system.