Google Gears trouble

After waiting for an unusually long time for a version of Google Gears to be released that was compatible with Firefox 3.5, so long so that a member of the Gears-users Google Group finally cobbled together their own version that Firefox 3.5 users could install temporarily until Google got their act together. Well they did and subsequently released Gears version 0.5.29.0. And now, inexplicably, Firefox users who have updated to 3.5.1 have once again found Gears to be incompatible.

Well, not quite.

While it is somewhat questionable why the developers of Gears decided to set the absolute max version of 0.5.29.0 to Firefox 3.5, this latest version of Gears, unlike past versions, does actually work with the latest and very needed bug fix to Firefox 3.5. But one of two things need to be done first though in order to get Gears working again.

• Install the Nightly Tester Tools extension and use the “Override all compatibility” button at the bottom of the Add-ons Manager dialogue box to get Gears working again (I’ve already tested this, Gears works fine once this is done).

or

• Go into “about:config” and set extensions.checkCompatibility to False and restart the browser (this also works just fine). Just remember to set it back to True when Gears is finally updated. Forgetting to do this may cause a bit of future havoc if you happen to install an extension that’s not actually compatible.

On a more personal note, I find Google’s recent behaviour regarding Firefox and Gears support to be rather baffling and unacceptable. They had full knowledge as to when the Firefox 3.5 was to be released and should have had a compatible version of Gears released within a couple of days…but they didn’t. Then, again with full knowledge that version 3.5.1 was just a matter of days away (and pre-releases free for downloading and testing), the newest version of Gears “breaks once again.

For someone like myself who, for the most part, really doesn’t have a problem with Google or the way they do business, I find this kind of recent behaviour quite perplexing.

Note: For those of who might have installed the developer’s version of Gears (0.5.25.0) in order to use Gears on Firefox 3.5 previously, this version needs to be uninstalled first prior to installing the official release. Otherwise, Google Gears homepage will only reinstall the Developer’s version again. The dev version can be easily uninstalled via the Add-ons Manager in Firefox. No Gears data should be lost during this uninstall.

The explanation behind the lack of support of Gears for testing pre-release builds of Firefox which, theoretically at least, would have paved the way for the immediate support of the new version once it became available, is that an entirely new build of Gears has to take place every time a new beta/RC build of Firefox comes available hence the lack of (public?) availability.

Hmmm, whatever.

However, for those of you that have been waiting patiently or not-so patiently for Gears support in Firefox 3.5 and who don’t mind testing out pre-release type software, the wait is over. A member of the Gears Users Google Group by the name of Geza Kovacs took the time to to put together 3.5 compatible Gears builds for Windows, Linux i386 and Linux x386_64 operating systems. Like any Add-on for Firefox these new Gears builds come as a “.xpi” file that installs just by clicking on the link. The download links are below:

Note: Clicking on the link will install the “.xpi” directly like any Firefox Add-on. Right-click and choose “Save link as” if you wish to download a copy of the file itself.

Windows:
http://gkovacs.xvm.mit.edu/google-gears/gears-win32-opt-0.5.25.0.xpi
Linux i386:
http://gkovacs.xvm.mit.edu/google-gears/gears-linux-0.5.25.0.xpi
Linux x86_64: 
http://gkovacs.xvm.mit.edu/google-gears/gears-linux-x86_64-0.5.25.0.xpi

Understanding that the above builds are developer’s builds and not official releases, make sure your comfortable with testing pre-release software before trying them out. For what it’s worth, I installed the Windows version as soon as I saw it available on the Gears Users Group and I haven’t experienced a single problem with it. All my Gears enabled sites have worked fine once I downloaded each site’s files into the Gears’ cache including the WordPress Admins for this site and my personal blog. And from what I’ve read on the above Group, no one else has encountered a problem using these builds either. From my experience using the Windows version the build has been rock stable. Thanks Geza!

Firefox 3.5 was released to the masses on June 30th and as usual certain extensions have since come up as incompatible. And as usual the Mozilla blame game is afoot with a number of Firefox users complaining that one or more of the 30 (more or less) extensions they have installed are no longer compatible and why the heck didn’t Mozilla take care of this while 3.5 was still in testing?

Why?

Because Mozilla is not responsible for extension compatibility, that’s why.

Now most Firefox users probably know this but there’s a very vocal group who apparently don’t. While I can understand that finding your favorite extension no longer usable can be very aggravating it’s rather important to make sure you know where you’re aiming before you start shooting flame and blame. As to who’s responsible for what is rather simple really:

Mozilla is responsible for Firefox development, security and bug fixing, that’s it.

Extension authors are responsible for their respective extension(s), even if it’s Google.

Mozilla decided to build an extension framework into their browser long ago but left it up to third party programmers to make use of it. Mozilla was good enough to host these extensions and later provided a set of standards that these extension authors must adhere to in order for their extension to be hosted. But Mozilla is neither responsible for any extension downloaded from the Firefox Add-ons site nor that any given extension is compatible with any particular version of Firefox.

As it stands, the majority of the most popular extensions were already updated before the final release date. Even many of the close seconds haven’t had a problem with 3.5 but for any extension that hasn’t been updated you’ll need to contact the extension’s author directly.

The current Firefox 3 series is by far a superior browser to version 2 in just about every way and it’s pretty much a safe bet by now that all of your favorite extensions you’re using in Firefox 2 are now supported for Firefox 3 with the possible exception of extensions no longer supported by the author. If one of your extensions is no longer supported by the author there’s not much the makers of Firefox can do about it.

The Internet has always been a dangerous place to cruise around in unprotected especially these days when phishing attacks and malicious advertisements are in abundance everywhere. Hijacks to innocent looking sites or duplications of well known sites is hardly uncommon in these times as well. And even as careful as I am I’ve found myself saved more than once by the built in protection afforded by Firefox 3.0.* and the Firefox 3.1 nightly builds. Much to my surprise I might add.

You can’t afford to take any chances these days and holding on to the older versions of Firefox or any other browser is just asking for trouble. And as always when upgrading from one major version of software to another, I recommend starting with a clean slate.

You can easily do this by exporting your current bookmarks from Firefox 2 first. Then take the time to check to see if your extensions are still listed on the Mozilla Add-ons site and what versions of Firefox they support. If one of your current extensions in no longer actively supported then chances are there’s a equivalent substitute available. You might also find that Firefox 3 already supports a feature or function natively that was once added by an extension in Firefox 2 so it’s worth checking that as well.

Once you’re satisfied with the availability of extensions then it’s just a matter of uninstalling the old browser and installing the new, importing your bookmarks and reinstalling your extensions. A bit of your time for a clean start is always worthwhile especially in the light that although Firefox 3 may look mostly the same up front, it’s a whole different ballgame underneath.

Note: If you happen to be one of the users that encounter high CPU usage when a site is loaded into a tab in Firefox 3 then you’ll need to take a minute and setup this easy fix. The problem occurs with certain combinations of hardware of any given computer but was not isolated as to which by the time Firefox 3 hit the streets Not all users are affected.

Firefox 3.1 nightly builds and the up and coming Firefox 3.1 beta 3 (in testing now) have this problem fixed thankfully.

This problem showed up in the middle of the development of Firefox 3.0 and although did not affect all users it affected a rather large portion of them, so much so that I received over 60 comments on that original post of mine (posted on both of my sites), the majority of which stated that the “fix” worked beautifully. Bug reports were posted and generally ignored and Firefox 3.0 was released without this problem being fixed however.

Then came the development of Firefox 3.1 and along with it came the same exact problem which was still able to be fixed by the above solution until one day the solution no longer worked. After some digging I found that it wasn’t the same bug causing the High CPU usage in the exact same manner as the the original but a whole new (unknown) problem altogether and that’s where my experience in the trade ran out. Too make a long story short, I took the time to trace the regression range (between which build# worked okay and which build# did not) down to two sequential hourly builds, one which did not exhibit the new problem and one that did. The related forum was posted to and a bug report was then filed but that was where things came to a seeming halt—it also virtually halted my testing as well. I couldn’t test a broken browser and no one was apparently listening.

Note: It might be of interest to note that I am not a programmer or developer, I’m what used to be called a beta tester which is not the same thing. There are those who can code and those who cannot. There are those who can troubleshoot in the field as well as the lab and those who cannot. I’m the latter in the former and a former in the latter. Thank you very much.

So here’s the 3.1 development producing build after build with not only the original problem as stated above but now with an additional problem that would make Firefox 3.1 virtually unusable for a rather large group of users once they upgraded unless both these problems were tracked down and fixed.

I didn’t abandon the Mozillazine forums though. In fact, I actually checked in on a regular basis and reading through the list of bug landings (fixed bugs) for any clue that things had been put to rights. I also installed various nightly builds of 3.1 from time to time to see if they fared any better but all to no avail and no follow up to the bug report even to tell me that I was way off base.

Okay…so it’s fixed…apparently.

I hadn’t tried the nightly builds of 3.1 for over two weeks so I really don’t know when these two issues were fixed nor the whys, how’s, or wherefores behind it but with yesterday’s nightly build of 3.1 (Minefield) with nothing but a default installation and settings, 3.1 beta2-pre fired up without a problem, loaded up my usual tabs and my CPU barely woke up for it. And so far I haven’t seen hide nor hair of those infamous problems (knock on whatever wood I can find). Now I can finally get on with the testing without fear of baking my poor single core CPU into something that resembles a hunk off a burnt steak fry.

Life is good again.

When the folks at Mozilla first started work on Firefox 3.0 and began releasing the nightly builds thereof I took an immediate interest in testing this new version as it was being built so I could have first hand knowledge as to where Mozilla was headed with this frisky little browser of theirs. The results of the Firefox development team’s effort, if I may be so bold to say, are pretty decent. Firefox 3, currently at 3.0.1, has gained well deserved credit for being the fastest, safest web browser out of those currently available. For the majority of users, it’s overall speed and behavior is excellent. Of course there’s always quirks to be found but that can be easily said about any browser. And so when work began on next version of Firefox, I had no choice but to call up the Firefox Profile Manager and make a new home for the Firefox 3.1 nightly builds to live.

Now I’m using these nightly builds for testing purposes, my daily perusing of the news, online emails and every badly coded and over-bloated site I can possibly find just to see how she fairs. Since the nightly builds are still only pre-Alpha 2, it’s not time yet to provide any real performance details but one thing does stand out—it’s already faster than current version of Firefox.

I first noticed this while viewing Google News’ main page in that the images almost instantly appeared during the page load or at least it seemed that way. So just out of curiosity I ran the same SunSpider Java Script Benchmark tests that Percy Cabello of Mozilla Links had run on the Firefox 3.0 beta’s back in march of this year. Here’s the results graph from his second round of tests he published on March 16th post (results are measured in milliseconds and “WebKit” referred to the latest build of Safari for Windows):

Why is this important? Percy explains in an earlier post that included his first round of tests:

As you may know, JavaScript is progressively becoming more important as we, users come to expect web applications to behave more like their desktop equivalents. For web developers, the top tool for doing this is JavaScript, the language used to program the different web page elements and in some cases, query the server for small pieces of data.

For Firefox, it is even more critical since the whole interface (extensions included) runs on JavaScript: open a context menu, a menu, a tab or a window, and there’s JavaScript at work all around connecting the underlying pieces.

This was a huge jump from Firefox 2 which came in at over 19,000ms in the first round of tests. The second round of Percy’s tests showed over a 3 times improvement in speed for that beta build of FX3 over it’s predecessor. And now it’s well into August already and I just had to run these same tests on the current development builds of Firefox 3.1 and these were the results:

Note: This is just a poor-boys test, nothing official here and not nearly as pretty as Percy’s.

Tests were run 3 times. Took best times out of three.

Okay, so it’s not the same type of huge difference and that stands to reason since 3.1 is just continuing on with what 3.0 started. However, considering the developers are still working on a Firefox 3,1 alpha 2 release, I was surprised to see that there indeed was a speed increase even if it was a slight one. When multiplied over all the Java scripts that Firefox has to handle even that small increase you see in the chart can be definitely noticeable. By the way, Opera 9.5 (final) shows nearly a 1900ms improvement over the previous beta version so those folks haven’t been slacking either and when the Internet Explorer development team delivers IE 8.0 beta 2 later this month, I’ll run another set of tests and include those as well as updated results for the latest FX3.1 builds.

Good to see the folks at Mozilla still working hard to improve my favorite browser.

Firefox 3.1, which is scheduled to ship before the end on the year, will incorporate new ways to filter the results shown in the Smart Location Bar’s drop down list. Something that many Firefox 3.0.x users are looking forward to having. One of the reasons that this could not be done in time for the release Firefox 3.0 is that “History” had yet to be incorporated into the SQLite database that currently takes care of such things as bookmark and tagging data.

At present these additional “filtering” functions consist of several new entries in 3.1’s “about:config” that allow the user to just about tailor the results shown in the drop down list just about any way they wish. Permanent changes such as restricting results to show only visited sites (taken from your “History”) for example, can be made using “about:config”. However, changing the results shown in the list “on the fly” so to speak can be taken care of right from the Location Bar itself.

For examples of how these new functions work together in Firefox 3.1 to provide the users the ability to get the results they want to see, Edward Lee, author of the Hide Unvisited extension for Firefox 3, was kind enough to write up a post about this very thing on his personal blog.

Looks like the “Smart Bar” is going to get all that much better. Can’t wait to see how the extension authors leverage these new functions.