|
|
||
Firefox and Global Extensions© Copyright Darrell Anderson. Considering that GNU/Linux is a multi-user environment, that I use GNU/Linux in that manner, and I have several user accounts, I cannot fathom having to install some two dozen extensions manually for each account. Starting with version 1.07, however, I struggled with installing Firefox extensions globally. Eventually, however, I solved the problem and the solution probably will be useful to others. As root I could install extensions globally, the extensions appeared in the user’s extensions dialog box, but the extensions would not work. The global extensions worked fine for root. I installed Firefox 1.5.0.7 using the Slackware package. No issues. I tested Firefox and all was well—although the basic program needed a lot of tweaking for my tastes. I began installing extensions using the -install-global-extension option. No issues. Testing the extensions as root presented no problems. Toggling to my normal user account, I could run Firefox just fine but the extensions failed to load. I discovered one reason why. While configuring and tweaking Firefox as root, I purposely deleted the DOM Inspector and Talkback extensions. I use the word purposely so all the don’t-use-root priests stay away. These extensions provide no value to me and never have. From within Firefox I deleted the extensions because with the Windows version of Firefox, the installation script provides users the option to install Firefox without installing those extensions. I presumed a tit-for-tat design for both versions of Firefox. I presumed I could do likewise in GNU/Linux. Not so! I had to reinstall those extensions—easily done using the explodepkg tool. After I restored those two extensions, I then could start Firefox as normal user and watch Firefox build the user extensions files (extensions.rdf, extensions.ini, and extensions.cache.) Remove those two extensions and the process stalls. Interestingly, after Firefox builds the user files, I could remove those two extensions and Firefox would not miss a beat after I globally installed additional extensions. I’m no expert on the specifics of the Firefox files and formats, but something exists that seems to require those two extensions for the initial installation. I do not pretend to know why. Regardless, thereafter those extensions need not exist and I globally installed three or four additional extensions after initializing my normal user account. I won’t pretend to know all of the quirks with this initializing and loading process. There certainly could be a flaw in my testing and resolution—I don’t know. I am only reporting what I saw. Because in Windows users essentially run as root all the time, installing extensions globally there probably is not a reasonable comparison or test. Possibly if I were to configure my Windows box to be as restrictive I might see similar results, but I do not possess the energy to know. But the mystery deepens. I noticed that even after I was able to get Firefox to run as normal user, several extensions simply refused to load. About half the extensions loaded and half did not. A real head scratcher and then the proverbial light bulb went on. Any time something works as root but not as normal user, I begin to inspect file permissions. I noticed that of the extensions that refused to load for normal user, that the extension was not packaged with appropriate internal file permissions. For example, in several of those extensions, the critical install.rdf file was stamped with 400 permissions. Of course, root could see those files and the extensions would load, but not for any other user. My SWAG is the developers of these particular extensions never tested their xpi install scripts globally. That is, they tested only by installing the extensions locally into the user’s directory. An additional guess is these developers probably are Windows users—basically a single-user environment where file permissions play no significant role. So there is evidence here of some lack-luster quality control and some conceptual misunderstandings by these developers. By modifying the file permissions to 744 for all files (not directories, just files) in the extensions directory, my normal user account no longer had a problem loading those extensions. And the mystery deepens. Firefox-GTK seems to often ignore the user.js configuration file. Several times I modified that file, and when loading, Firefox is supposed to absorb those personal modifications on-the-fly into the prefs.js file. This is not the case. I cannot repeat the results in any dependable manner, but I observed that sometimes Firefox fails to load the user.js file. Very frustrating because when I customize Firefox, I copy changes from prefs.js to user.js in order to make those mods permanent. I have been doing this going way back to the Netscape 4.0x days. With my Slackware boxes, I then replicate that user.js file to my normal user accounts (and yes, I ensure that file permissions are correct after copying). The idea is I should be able to modify the user.js file and Firefox automatically should be updated and tweaked. No so and I have no answer why. I do not have this problem in Firefox-Windows. Long term solution?
Firefox-Windows is an acceptable program, although the XUL interface is sluggish. Contrarily, I cannot recommend Firefox-GTK with any seriousness. As I surfed the web searching for help with this issue, I noticed many people struggling with installing extensions globally. By design, GNU/Linux is a multi-user operating system and installing extensions globally should be routine, second nature, and the default option. As an old friend often said to me, “This stuff is not ready for prime time.” Finis. |
||