User: Password:
|
|
Subscribe / Log in / New account

Test driving Firefox 3

The Firefox 3.0 (FF3) development team has been busy, releasing a steady stream of alphas over the last six months, in preparation for a final release late this year. The latest release is Alpha 5, which seems like a good time to check in on the project and see what changes have been made. The project, codenamed Gran Paradiso, maintains an extensive set of documents on its planning center wiki. These documents are worth a look for anyone interested in what features are planned, but also provide insight into the planning process itself.

[Firefox 3.0 Main Window] The first thing to notice is that there is not much different from Firefox 2.0, at least in the main window. The familiar buttons and bars are present in their usual locations, the menus remain essentially the same, though the performance seems a bit snappier. The main window is likely to remain the same through the final release, but much of the rest of the UI will be tweaked. So far, the team has focused more on the underlying code, while using various blogs and wiki pages to mock up the UI.

Much of the new functionality is under the covers in the Gecko 1.9 rendering engine. A specific goal of the engine development team was to pass the Acid2 browser test and they have succeeded in doing that. Switching the engine to use the Cairo 2D graphics library will provide support for SVG, PostScript, PDF and other formats. Performance enhancements and a more native look, especially for the Mac, are also on tap for FF3.

The biggest new feature for users has not yet appeared in the browser. Places is a feature meant to unify bookmarks, history and RSS feeds, while providing a means to tag them to help organize them. In order to do that, FF3 is storing the Places information in an SQLite database. This database will also be available to Firefox Add-ons which can then offer other ways to view and organize them.

Using SQLite for bookmarks has been enabled for Alpha 5, with numerous warnings about making a backup of your bookmarks file before running it. Tagging, history and RSS feeds are still awaiting a UI before their storage in the SQLite database is enabled.

[Firefox 3.0 Page Info] One UI element that has been updated is the page info popup (image at left), which received an overhaul bringing its look more in line with other tabbed popups, Preferences for example. More work of that sort can be expected as consistency within the UI is definitely a goal for FF3. The content handling interface is part of that work. Earlier versions had different dialog boxes depending on how the content was retrieved, which caused some confusion in users, so FF3 will unify those dialogs into one consistent view.

Security is another area where the developers are putting in significant effort. Providing users with feedback, about the security of a site, without overwhelming them with warnings and popups, is a difficult problem, but some interesting ideas are emerging. With fairly simple UI changes, user confusion can be reduced. Modifying the location bar to remove the "favicon" (which some malicious sites set to the lock icon) and to highlight just the domain portion of the URL can go a long way towards helping users determine what sites they are visiting. Mozilla is also working with Google to generate a list of sites delivering malicious content and FF3 will block access to those sites.

One worrisome development is the removal of the "same domain" restriction on XMLHttpRequest (XHR) calls. XHR is the workhorse of the AJAX style of browser interaction and web designers have long chafed under the restriction that JavaScript could only "call home". The World Wide Web Consortium (W3C) has some proposals on lifting that restriction by using "access control" lists and the FF3 team plans to implement them. The current restrictions have served us well, at least from a security perspective; hopefully this change has been well thought out.

Another big addition, still in the "coming soon" category, is the addition of more offline capabilities to the browser. Being able to run web applications when not connected to the internet is one of the main goals. In order to do that, the history of pages will have to include the state of the Document Object Model (DOM) and the execution state of JavaScript embedded in the page. With a big enough browser cache, this would allow enough context to re-browse pages from weeks ago, even when offline.

Overall, FF3 looks like an exciting release with a wide variety of new features. The current alpha does not really provide even an approximation of the full feature set, but it is still worth a look. At roughly the halfway point in FF3 development, great strides have been made with more to come.


(Log in to post comments)

Favicons

Posted Jun 21, 2007 2:47 UTC (Thu) by mattdm (subscriber, #18) [Link]

I hope that there's a way to turn favicons in the URL bar back on, for users who understand what it is and aren't confused by it being a lock icon or anything else.

Favicons

Posted Jun 21, 2007 10:52 UTC (Thu) by jengelh (subscriber, #33263) [Link]

Especially because the lock icon appears on the __right__ side of the URL bar (in FF2), not on the left where the favicon is.

Test driving Firefox 3

Posted Jun 21, 2007 3:30 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

At least Firefox still has a decent-sized document reload button unlike (ahem) IE7. I swear the first time I ran IE7 I searched for 5 minutes looking for the blasted refresh button!

Test driving Firefox 3

Posted Jun 21, 2007 11:33 UTC (Thu) by jengelh (subscriber, #33263) [Link]

Actually, no. The button size is not a feature of IE, but of the Windows environment. And hence, Windows 95 and 98 have the biggest button (32x32 _plus_ text), see
http://www.guidebookgallery.org/pics/gui/applications/int...
XP has only a 32x32 without text, and so does Firefox.

IE7... I don't even want to look.

Icons with Text in Firefox

Posted Jun 21, 2007 14:54 UTC (Thu) by GreyWizard (guest, #1026) [Link]

Icons without text is the default for Firefox, but by right clicking and selecting customize a user has the option to select icons with text instead. (For most users the text would be a waste of valuable screen space but there's no accounting for taste.)

I wouldn't be surprised if IE had a similar feature somewhere.

Test driving Firefox 3

Posted Jun 21, 2007 12:17 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

F5, same as it ever was.

Test driving Firefox 3

Posted Jun 21, 2007 4:06 UTC (Thu) by ssavitzky (guest, #2855) [Link]

I really hope there's a way to go back to a plain-text bookmark file. The last thing I need is to have my bookmarks in some easily-corrupted binary file. Also, I use the fact that the bookmarks are readable as HTML -- it means I can keep separate bookmark files on different machines, but still swap them around and refer to them.

Python scripting?

Posted Jun 21, 2007 7:38 UTC (Thu) by AnswerGuy (subscriber, #1256) [Link]

I presume you could easily whip up a suite a Python SQLite utilities for
dumping, merging, and manipulated your bookmarks files in various ways.

(First such util would dump the whole mess an HTML/XML file ... or tab or CSV delimited, etc; and would be able to import back an modified version (merging or just blindly adding).

JimD

Python scripting?

Posted Jun 21, 2007 12:52 UTC (Thu) by Sho (subscriber, #8956) [Link]

> (First such util would dump the whole mess an HTML/XML file ... or tab or CSV delimited, etc; and would be able to import back an modified version (merging or just blindly adding).

The right format here would be XBEL, which most other open source browsers are already using as storage or exchange format for bookmarks: http://pyxml.sourceforge.net/topics/xbel/

Python scripting?

Posted Jun 22, 2007 2:28 UTC (Fri) by jamesh (guest, #1159) [Link]

Given their aim (storing both history and bookmarks in a single data store that can be easily searched), you are talking about a lot of information here.

With XBEL, you'd end up having to parse the XML and either store it in memory for searching/display or writing it back out to disk in a form that can be searched quickly. And if you aren't going to be using the XBEL data most of the time, why not make the more efficient form the master and keep XBEL for exchange?

Test driving Firefox 3

Posted Jun 21, 2007 11:06 UTC (Thu) by jamesh (guest, #1159) [Link]

SQLite doesn't seem to be that prone to corruption (especially if you compare it to Berkeley DB).

But look on the bright side. They could have used mork.

Test driving Firefox 3

Posted Jun 21, 2007 15:07 UTC (Thu) by iabervon (subscriber, #722) [Link]

I've heard that it keeps bookmarks.html up to date with the contents of the database, although I haven't tested it myself.

Test driving Firefox 3

Posted Jun 22, 2007 3:15 UTC (Fri) by ssavitzky (guest, #2855) [Link]

That would be good. Database for searching while the program is running, file for organizing folders and static storage. Not sure I believe it, though.

Test driving Firefox 3

Posted Jun 22, 2007 3:42 UTC (Fri) by iabervon (subscriber, #722) [Link]

Oh, it actually uses the database for storage, but provides bookmarks.html in case you want it for something or, I guess, if the database gets messed up.

Threading

Posted Jun 23, 2007 17:27 UTC (Sat) by mikov (subscriber, #33179) [Link]

Any word at all on resolving the fundamental threading problems in Firefox ? My absolutely biggest gripe is that it is impossible to kill a single Firefox window. The second is that everything, including all separate windows, is running in the same thread.

Threading

Posted Jun 24, 2007 20:16 UTC (Sun) by k8to (subscriber, #15413) [Link]

Agreed five times over.

The second item in my hitlist is if they are going to *finally* clean up the focus bugs so I can lose the joy of having to click on something 8-10 times to get the focus to go there.

Threading

Posted Jun 30, 2007 11:29 UTC (Sat) by oak (guest, #2786) [Link]

This could be a problem with all the JavaScript scripts on the page
stealing (setting) focuses from each other on certain events...

Threading

Posted Jun 30, 2007 11:44 UTC (Sat) by oak (guest, #2786) [Link]

> My absolutely biggest gripe is that it is impossible to kill a single
Firefox window.

I.e. all windows belong to same process. I think the reason why this is
done is because browser startup is slow and due to amount of code, engine
state/initialization etc, it would also take quite a bit of additional
memory at startup. Also, with each window being in a separate process,
you would notice the heap fragmentation caused by the dynamic (JS, Flash
etc) HTML page contents much sooner (each separate window taking after a
day 1/2GB of RAM instead of single Browser process using that much).

It would be nice if Firefox binary would have an option that when you
start it from the command line it would start a new process instead of
asking an already existing Firefox instance to open a new window though...

> The second is that everything, including all separate windows, is
running in the same thread.

One should use separate threads only for separate functionality.
Otherwise the needed locking will kill your performance. Actually I think
it could be better if Firefox would get rid of threading completely, I
think most of the work is done in the main thread anyway, but use of
threads (at all) means that all mallocs within C-library need to be done
with locking. :-)

(Linking against thread library automatically replaces some functions from
C-library with their thread-safe functions. This can in some rare cases
lead to funny problems with dlopen()ed libs if one does linking wrong.)

Threading

Posted Jun 30, 2007 22:50 UTC (Sat) by mikov (subscriber, #33179) [Link]

One should use separate threads only for separate functionality. Otherwise the needed locking will kill your performance. Actually I think it could be better if Firefox would get rid of threading completely, I think most of the work is done in the main thread anyway, but use of threads (at all) means that all mallocs within C-library need to be done with locking. :-)

I have to disagree. Speaking in general, there are no hard and fast rules in threading and you can't say that locking kills performance without a more specific context. What does "separate functionality" mean anyway ?

It is true that for some (many?) kinds of servers a single thread can achieve better throughput, but for GUI-s this is plain wrong. In a GUI you should be concerned with latency before all, and not with absolute performance. The UI should react immediately to every user action, even if it takes a bit longer to actually complete it.

I do agree that having an option to open new windows in a separate process would go a long way towards improving the situation.

Test driving Firefox 3

Posted Jun 29, 2007 4:25 UTC (Fri) by cyrus (subscriber, #36858) [Link]

I've always asked myself why Firefox on Linux feels so weird on certain websites. Just load up http://www.linuxactionshow.com/ and scroll with your mouse wheel. Can you feel the jerkiness? This is not fixed in Firefox 3 Alpha 5. And by the way.. I first thought this might be problem of the Gecko engine, but Opera has the same problem.. The site is smooth when using Firefox under Windows.

Another thing: Opening a new tab in Firefox 2 gives you a little retarded half-second "flash". The same can be observed when opening a new tab in the Gnome terminal. This is only partly fixed in Firefox 3 (happens for the first new tab you open, but not for the third, fourth, and so on.., but when you close all tabs and only got one window open and open a new tab it "flashes" again). This does not happen on Windows. Does anyone have an idea what might cause this? For me this is really ugly and if you use your browser several hours a day like I do, the "little things" can get pretty annoying :-(

background-attachment

Posted Jul 5, 2007 2:10 UTC (Thu) by midg3t (guest, #30998) [Link]

The jerkiness is because the background image is fixed. The rest of the document can't be rendered off-screen for quick scrolling because the position of the background relative to the rest of the page (text, etc) is unknown untill the scrolling actually takes place.

The culprit is usually the background-attachment CSS property. Everybody should leave it at the default value of "scroll".


Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds