因此Nathan Weinberg懷疑Google在不久的將來要收購Firefox了，他覺得一個商業(yè)公司不太可能研究自己沒有的產品的性能。
Ben Goodger的Blog帖子：http://weblogs.mozillazine.org/ben/archives/009210.html
Improving Tabbed Browsing
A lot of us are fans of tabbed browsing. It's one of the most useful changes in window and document management since the Task Bar on Windows. People who like to work with multiple documents like quick, convenient access to them. It's part of the reason Microsoft moved Office to a SDI model. That said, Firefox is a browser for everybody, and a lot of people don't use a lot of windows. In one of the PDC videos released a month or so back, a Microsoft representative said that they had done studies that showed that users generally had no more than 5 windows open at a time. This surprised them because they, like most of us, were used to browsing with tens of windows. The challenges that face us building the Firefox UI is how to make Tabbed Browsing useful to those who want it, discoverable to those whose lives would be made easier by it, and transparent to those who don't need it.
The first step in this process was to look at what people were used to right now. Most people are still using IE, and the model there, at least until IE7 ships and consumes the IE marketshare numbers, and the model in IE6 is a document-window based one. So, we should look at how windows work, and how tabs work, and see if there are any areas where tabs don't work as well as windows and try and improve those areas, as well as other unrelated improvements.
Here at Google, we did some usability studies on the tabbed browsing feature. Our usability analyst designed a study to see how well people responded to tabs and how easily they were able to switch between them and close them. In these studies, a build of Firefox 1.5b1 was used, with a single configuration change - the new "targeted links open new tabs instead of windows" preference was set, to force users to encounter tabs as they browsed around (rather than having them hear a spiel about the tabbed browsing user interface and have to think to use it, as we're all trained to do by now, this seemed a more natural flow). The results showed that the set of people sampled were generally capable of recognizing the tab strip, and switching between documents. We found though that unpredictable behavior of the back button (new tab = blank session history) is still a problem, since users expect clicking back to go back. What we also found is that the users we sampled were by and large using the context menu to close tabs. Some tried to close the entire browser window first, and most paused before trying the context menu. We also found people were surprised by the z-index used by the virtual stack establed by the tabbed browser. Tabs opened by links with target attributes, when closed, select the adjacent tab, not the tab that opened them. All our subjects used computers fairly frequently as part of their daily work, and seemed familiar with the basic GUI concepts of the environment.
Some of the issues felt by the test subjects echo ones that we have felt personally, but probably moreso since we use tabs pretty heavily. At Google, we are constantly bit by the z-index issue since we use a lot of web apps (like web mail), and links opened from web mail, forums and other such apps generally open things in new windows. When you have targeted links open new windows, when you close the opened window the page you came from is usually the window behind it, so it works out nicely. With tabs, not so much.
So here are a couple of things we have been experimenting with.
Put close buttons on the tabs. This makes it a lot easier to close tabs with the mouse. People weren't seeing the close box in the usability test. It's also out of the way and not connected with what's actually being closed. Mindful of stealing space from the tab strip when there are many tabs, the close boxes on inactive tabs are hidden when the tab width falls below a certain minimum value.
Implement a simple heuristic for z-index handling. When a new tab is opened in the foreground by any operation (targeted link, external application link, Ctrl+T, etc.), set the new tab's "owner" to be the tab that opened it. When the user closes it, select the owner, not the next adjacent. So that the mass-close condition doesn't become annoying (with selection jumping around as many tabs are quickly closed), forget the owner property when the tab is switched away from. This more closely matches behavior of window z-index.
While we're here, consolidate the preferences for links sent from external applications vs. targeted links internally into a single pref: "Open links that would open new windows in tabs" instead, since web applications are becoming more advanced to the point where it seems odd that clicking on a link in Thunderbird should open a link one way, but clicking on a link in GMail should open it a different way.
Here's a screenshot of the tab strip:
I used this opportunity to significantly polish the appearance of the tabs in the selected and non-selected state, as well as the focus rings. Also, on MacOS X the close button appears to the left of the favicon, similar to other Mac browsers and Mac windows in general.
We've been testing these changes and they're working really well. I've been producing some test builds. I'll have them linked here shortly. The Windows one is here. There are older Mac and Linux ones in the Tabs experimental directory on ftp.mozilla.org. Try them out and let us know what you think.