Closed Bug 392870 Opened 17 years ago Closed 16 years ago

Easy discoverability of Tabbed Browsing for new users

Categories

(Firefox :: General, defect, P4)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.1b1

People

(Reporter: ronin.achilles, Assigned: dao)

References

Details

Attachments

(2 files, 5 obsolete files)

updated, landed patch
8.37 KB, patch
Details | Diff | Splinter Review
Windows Live Toolbar Tabs
76.94 KB, application/zip
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 I am sure this bug has been filed in various forms earlier, but I really fail to grasp as to the intent of it not being implemented. It has been mentioned in multiple forums/studies that new users more often than not are never able to discover the tabbed browsing feature of Firefox. Every other browser, on their initial start-up make the tabbed browsing obvious (either by showing the Tab Bar or by having a 'New Tab' button on the toolbar). But in Firefox, if you don't already know, or have not been guided by someone, I believe it is by sheer luck that a user will look under File -> New Tab to discover this very basic feature. Two obvious and easy ways to implement it: a. Enable the 'Always Show Tab Bar' option by default b. Add the 'New Tab' button to the toolbar by default Please implement atleast one of these for Firefox 3. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Flags: blocking-firefox3?
Ok, bugmorphing: a) Show tabstrip by default b) Closing the last tab will always close the window
Assignee: nobody → mconnor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: --- → Firefox 3 M9
moving out bugs that don't need to block b1
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Attached patch patch (obsolete) — — Splinter Review
Attachment #287842 - Flags: review?(mconnor)
Attached patch patch v2 (obsolete) — — Splinter Review
moving prefs to the already existing "Tab browser preferences" section
Attachment #287842 - Attachment is obsolete: true
Attachment #287843 - Flags: review?(mconnor)
Attachment #287842 - Flags: review?(mconnor)
Comment on attachment 287843 [details] [diff] [review] patch v2 >Index: browser/base/content/tabbrowser.xml >=================================================================== >RCS file: /cvsroot/mozilla/browser/base/content/tabbrowser.xml,v >retrieving revision 1.247 >diff -u -8 -p -r1.247 tabbrowser.xml >--- browser/base/content/tabbrowser.xml 29 Oct 2007 03:03:46 -0000 1.247 >+++ browser/base/content/tabbrowser.xml 8 Nov 2007 15:11:06 -0000 >@@ -1337,20 +1337,24 @@ > <parameter name="aTab"/> > <body> > <![CDATA[ > this._browsers = null; // invalidate cache > if (aTab.localName != "tab") > aTab = this.mCurrentTab; > > var l = this.mTabContainer.childNodes.length; >- if (l == 1 && this.mPrefs.getBoolPref("browser.tabs.autoHide")) { >- // hide the tab bar >- this.mPrefs.setBoolPref("browser.tabs.forceHide", true); >- this.setStripVisibilityTo(false); >+ if (l == 1) { >+ if (this.mPrefs.getBoolPref("browser.tabs.autoHide")) { >+ // hide the tab bar >+ this.mPrefs.setBoolPref("browser.tabs.forceHide", true); >+ this.setStripVisibilityTo(false); >+ } else { >+ closeWindow(true); >+ } > return; > } > > var ds = this.getBrowserForTab(aTab).docShell; > if (ds.contentViewer && !ds.contentViewer.permitUnload()) > return; > > // see notes in addTab This block, as far as I can tell, should be removed in favour of just closing the window if i == 1. This is wacky legacy cruft that needs to die. You also need to fix BrowserCloseTabOrWindow() in browser.js to handle the non-tabbrowser UI hooks. >Index: modules/libpref/src/init/all.js >-// xxxbsmedberg more toolkit prefs? >-// Tab browser preferences. >-pref("browser.tabs.autoHide", true); >-pref("browser.tabs.forceHide", false); >-pref("browser.tabs.warnOnClose", true); >-pref("browser.tabs.warnOnCloseOther", true); >-pref("browser.tabs.warnOnOpen", true); >-pref("browser.tabs.maxOpenBeforeWarn", 15); >-// 0 = append, 1 = replace >-pref("browser.tabs.loadGroup", 1); >- > pref("toolkit.scrollbox.smoothScroll", true); > pref("toolkit.scrollbox.scrollIncrement", 20); > pref("toolkit.scrollbox.clickToScroll.scrollDelay", 150); > >-// lets new tab/window load something different than first window >-// -1 - use navigator startup preference >-// 0 - loads blank page >-// 1 - loads home page >-// 2 - loads last page visited >-pref("browser.tabs.loadOnNewTab", 0); >-pref("browser.windows.loadOnNewWindow", 1); >- are we the only consumers of these prefs?
Attachment #287843 - Flags: review?(mconnor) → review-
Attached patch patch v3 (obsolete) — — Splinter Review
Attachment #287843 - Attachment is obsolete: true
Attachment #287852 - Flags: review?(mconnor)
Comment on attachment 287852 [details] [diff] [review] patch v3 r=me on this
Attachment #287852 - Flags: review?(mconnor) → review+
So is this ready to land or is there something to wait for?
Attachment #287852 - Flags: review?(neil)
OS: Windows Vista → All
Hardware: PC → All
Version: unspecified → Trunk
Comment on attachment 287852 [details] [diff] [review] patch v3 >Index: suite/browser/browser-prefs.js ... >+pref("browser.tabs.warnOnOpen", true); >+pref("browser.tabs.maxOpenBeforeWarn", 15); We don't use these. r=me with this fixed.
Attachment #287852 - Flags: review?(neil) → review+
Attached patch for check-in (obsolete) — — Splinter Review
Attachment #287852 - Attachment is obsolete: true
taking the bug officially
Assignee: mconnor → dao
Keywords: checkin-needed
Blocks: 348031
Checking in browser/app/profile/firefox.js; /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js new revision: 1.220; previous revision: 1.219 done Checking in browser/base/content/browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.883; previous revision: 1.882 done Checking in browser/base/content/tabbrowser.xml; /cvsroot/mozilla/browser/base/content/tabbrowser.xml,v <-- tabbrowser.xml new revision: 1.248; previous revision: 1.247 done Checking in modules/libpref/src/init/all.js; /cvsroot/mozilla/modules/libpref/src/init/all.js,v <-- all.js new revision: 3.698; previous revision: 3.697 done Checking in suite/browser/browser-prefs.js; /cvsroot/mozilla/suite/browser/browser-prefs.js,v <-- browser-prefs.js new revision: 1.67; previous revision: 1.66 done
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: Firefox 3 Mx → Firefox 3 M10
Backed this out as a possible cause of the Ts regression on the perf tinderboxen.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #5) > This block, as far as I can tell, should be removed in favour of just closing > the window if i == 1. This is wacky legacy cruft that needs to die. I'm concerned about this change... Does this patch leave any way to restore Firefox 2 behavior (on Windows), so that it's possible to close the last page without shutting Firefox down? I don't want to have to consider whether the page I'm looking at is coincidentally the last, before hitting Ctrl-W.
(In reply to comment #13) > Backed this out as a possible cause of the Ts regression on the perf > tinderboxen. So this was a Txul win at the same time and only on Linux, right? I have no idea what that means. As far as I can tell, the patch didn't add anything to the startup path.
Priority: -- → P2
reed, can you give this another try? <dao> gavin|, any idea what was going on with bug 392870? <gavin|> dao: not offhand.. did anyone follow up to ensure that it actually was the cause? <gavin|> reed's comment says "possible"? <dao> gavin|, not really, but txul went back up and ts went back down after the backout <gavin|> should try checking it in again, I guess
Keywords: checkin-needed
The back out proved that this was indeed the cause of the Ts jump and the Txul win. The Ts jump could be seen on all platforms, but I don't remember if the Txul win was seen on all platforms (I just remember seeing it on Linux). I can try relanding it again, but I'm not sure what that is going to accomplish when it just causes a large Ts hit unless you are wanting numbers, etc.?
Numbers won't really help, as I couldn't explain any startup regression. So if the regression comes back (I didn't see it on Windows and Mac, btw), we either have to leave the patch in and file a new bug or back it out and unassign this one from me. Otherwise, assuming nobody else has a hint, this bug will just linger in the REOPENED state forever.
So I've read the patch a dozen times and apparently I missed the most important change: it sets browser.tabs.autoHide to false. That's where perf impact is expectable, maybe even unavoidable. However, that doesn't explain the Txul win, which still indicates that something strange was going on.
Need to hold off on this for some of Ryan's tabstrip cleanup to land so we know what the real cost is. Though, I still don't know why this helped Txul and hurt Ts, such a result doesn't entirely make sense...
Depends on: 387345
Keywords: checkin-needed
Whiteboard: [has patch][has reviews]
Keywords: checkin-needed
Relanded. Leaving open for now until I see perf numbers. Checking in browser/app/profile/firefox.js; /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js new revision: 1.229; previous revision: 1.228 done Checking in browser/base/content/browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.897; previous revision: 1.896 done Checking in browser/base/content/tabbrowser.xml; /cvsroot/mozilla/browser/base/content/tabbrowser.xml,v <-- tabbrowser.xml new revision: 1.252; previous revision: 1.251 done Checking in modules/libpref/src/init/all.js; /cvsroot/mozilla/modules/libpref/src/init/all.js,v <-- all.js new revision: 3.704; previous revision: 3.703 done Checking in suite/browser/browser-prefs.js; /cvsroot/mozilla/suite/browser/browser-prefs.js,v <-- browser-prefs.js new revision: 1.72; previous revision: 1.71 done
Keywords: checkin-needed
Still a bad perf regression. Linux: BEFORE -- Txul:226ms Ts:909ms AFTER -- Txul:234ms Ts:934ms Mac: BEFORE -- Txul:153ms Ts:841ms AFTER -- Txul:152ms Ts:881ms Win: BEFORE -- Txul:452ms Ts:1843ms AFTER -- Txul:459ms Ts:1844ms Win Talos: BEFORE -- ts_T: 2306.74 tp_l_T: 897.06 tp_pbytes_T: 68171277.89 tp_memset_T: 76511190.83 tp_%cpu_T: 69.35 AFTER -- ts_T: 2333.95 tp_l_T: 912.65 tp_pbytes_T: 68022663.45 tp_memset_T: 76161439.92 tp_%cpu_T: 70.26
Attachment #287920 - Attachment description: for check-in → for check-in (checked in)
mconnor needs to make a decision.
Comment on attachment 287920 [details] [diff] [review] for check-in It was backed out...
Attachment #287920 - Attachment description: for check-in (checked in) → for check-in
I don't see the point of the changes mconnor proposed in comment 1. This won't expose any actions that create tabs (except in context menus and double-clicking the empty space of the tab bar), so I don't think it will really help users discover how to use tabbed browsing. It has a lot of drawbacks, too: it takes up 29 pixels vertical space (even for users who don't multitask at all), slows down Firefox startup, and makes Firefox needlessly different from Safari. I think showing the "new tab" button by default would make more sense than showing the tab bar by default.
Yes, I vote for showing the New Tab button by default. Closing the last tab definitely shouldn't close the window. That's a bad idea. (A related note: an animation when opening the tab strip would be cool...)
Given the performance hit with enabling the Tab Bar by default as well as the trifle odd and probably unexpected behavior of the window closing with the last tab, I too am in the favor of showing the 'New Tab' button by default. Is there any specific reason why this shouldn't be the case (in terms of performance or any other side-effects)? And while an argument can be made saying that almost every other button (Print, Bookmarks etc.) will then have a case to be shown by default, I think that's not necessarily true. A New Tab button, IMO is as integral to a Tabbed Browser, and should be as easily discoverable as a Back/Forward button right from the first time a user launches the browser.
Target Milestone: Firefox 3 M10 → ---
Whiteboard: [has patch][has reviews] → [has patch][has reviews][wontfix?]
Attached patch updated to trunk (obsolete) — — Splinter Review
Attachment #287920 - Attachment is obsolete: true
For me, tabbed browsing is really useful only if you use middle clicking (alt+enter is also nice thing). I really have no idea how to make middle clicking discoverable, as there is also no way of making left click discoverable, right ;)? I don't think that one will see big improvements if he is just able to open tabs. On the other hand, as stated above, many people will see downsides if tabs are shown by default. I would propose the following thing: while one types address, Firefox currently shows only Go button in location bar. You could also add new tab button before it. I think that this doesn't bother anyone, and it might help some people at least to start using tabs.
P4, think we'll have to wait until next cycle to try to solve the txul/ts hit involved in showing more chrome by default.
Priority: P2 → P4
Mike: Until then, just put the New Tab button on the tab bar by default. Firefox, in its current state, looks like a non-tabbed browser.
Mconnor: Until then, just put the New Tab button on the tab bar by default. Firefox, in its current state, looks like a non-tabbed browser.
Oops... looks like I hit submit before I finished the post. (Just I don't know why I didn't get a mid-air collision warning.)
Assignee: dao → nobody
Status: REOPENED → NEW
Assignee: nobody → dao
bug 423105 filed for showing the new tab button on toolbar as a alternative solution instead of showing the tab bar by default which is currently having performance problems.
Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Assignee: dao → nobody
Changing the Bug Definition since the patch did not work out fine for 3.0. Possibly, simply adding a New Tab Button by default on the chrome (toolbar or tabbar) could work.
Alias: NewTabButton
Summary: Easy discoverability of Tabbed Browsing for new users → Add a New Tab Button to the Tabbar (or show the Toolbar button by Default)
Flags: blocking-firefox3.1?
(In reply to comment #39) > Changing the Bug Definition since the patch did not work out fine for 3.0. > Possibly, simply adding a New Tab Button by default on the chrome (toolbar or > tabbar) could work. This is also what was requested in bug 288541 - that bug was wontfixed with "We're not going to do this by default, for reasons explained in other places many times" a long time ago. (I haven't been able to find the "other places" anywhere...)
Alias: NewTabButton
Summary: Add a New Tab Button to the Tabbar (or show the Toolbar button by Default) → Easy discoverability of Tabbed Browsing for new users
It was decided to accept the Ts hit, as the new number will more realistic anyway (e.g. for session restore, or first-run with two tabs). This also allows us to actually track regressions and improvements in that area. http://hg.mozilla.org/mozilla-central/rev/26311b805c7a
Assignee: nobody → dao
Status: NEW → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews][wontfix?]
Target Milestone: --- → Firefox 3.1b1
Attachment #300107 - Attachment is obsolete: true
Does this mean we need an extension like BlankLast once more, to prevent the browser from shutting down all the time? I think it's unintuitive that in the case of the last tab "Ctrl-W" changes meaning and becomes "Alt-F4".
(In reply to comment #43) > Does this mean we need an extension like BlankLast once more, to prevent the > browser from shutting down all the time? Yes.
Blocks: 455756
I don't get why this change was sneaked in with "improving the discoverability of tabbed browsing", i.e. showing the tab bar by default. Firefox is a multi-document app, closing the last document closes no other MDI application. Sigh.
(In reply to comment #45) > I don't get why this change was sneaked in with "improving the discoverability > of tabbed browsing", i.e. showing the tab bar by default. That change wasn't sneaked in but is part of this bug as well as always showing the tab bar, per comment 1.
Yeah, I know this was mconnor's spec (and I raised my concerns in comment #14) But he didn't provide an explanation. On Mac (which he uses) this is OK, Firefox keeps running after the window closed. On Windows the user has to wait for Firefox' 5-10 seconds startup time, before he can continue. I'd like a word from beltzner...
Depends on: 455852
Depends on: 455864
Blocks: 400398
OT: I just hate how this affects my workflow right now =(
Always showing tabbar is OK, but why make Firefox close when the last tab is closed? It's really annoying. And how it can improve "discoverability of tabbed browsing". What's the sense of it?
(In reply to comment #49) > Always showing tabbar is OK, but why make Firefox close when the last tab is > closed? It's really annoying. And how it can improve "discoverability of tabbed > browsing". What's the sense of it? I agree. Maybe make it so that when the last tab is closed, it becomes empty, and if it's closed again, only then close the browser window.
(In reply to comment #0) > Every other browser, on their > initial start-up make the tabbed browsing obvious (either by showing the Tab > Bar or by having a 'New Tab' button on the toolbar). ... > > Two obvious and easy ways to implement it: > a. Enable the 'Always Show Tab Bar' option by default This would not make the feature more discoverable than it currently is: on initial startup (after install/upgrade) Firefox *does* show the tab bar (because it starts with two tabs), with a big arrow pointing to the "close tab" button. It is also worth considering that the option to get back the old behaviour (no tab bar when there's a single tab) is even less discoverable (perhaps almost impossible to discover) for users who have never used tabbed browsing before. Many of those users who haven't used tabs before might be quite annoyed if that single space-wasting tab is forced on them. So with the targeted users in mind (who still haven't heard about File -> New Tab, or simply didn't care to use it), is this really an improvement, or does it make the browser worse for them?
Depends on: 456002
Depends on: 455990
Suggestion: Why don't we follow Windows Live Toolbar - Tabs on this where it defaults to a page describing what tabs are and how to use them
I agree with Horvat. This patch is just plain unnecessary and I was a bit bugged as to why it suddenly appeared in the nightlies. This should not be included in Firefox itself, but rather a tip should appear in the first two tabs that Firefox launches on a fresh install/clean profile. I think Firefox used to have a webpage that said "press the red x to close this tab" and everybody saw this when they first installed Firefox 2. There can be an extra tip in the webpage that says "did you notice the tabbing ability" or something like that. There's absolutely no need to constantly remind users afterwards like Internet Explorer does. It just adds extra code to Firefox and I think it is also an insult to the intelligence of Firefox users.
So, can this patch be "undone" or is it carved in stone now? Where should we vote against it? Firefox is MDI app, you may open&close tabs (=documents) inside it, but the app itself should remain open until you clearly command it to close via "File -> Exit". That's the way all MDI apps do. It's logical and predictable behavior. But the logic of this patch I can't understand.
Showing the tabbar always is good behaviour. Changing the semantics of the close-tab button click (or close-tab accelerator key) under the user's feet to close-application is bad, BAD behaviour. (Keep in mind that this kills all session cookies, can run things like the private data purger, can trigger an add-on install/uninstall or Firefox upgrade and all manner of other behaviour that the user probably doesn't want to happen by accident.) There are many solutions as mentioned: 1) Closing last tab replaces it with a blank page tab 2) Solo tabs have no close button 3) Closing last tab leaves the tab bar blank (with just new tab button visible) My preference is a combination of 1 & 2 --- namely, closing the last tab replaces it with a blank page tab that has no close button on it. No semantics are ever violated and users know exactly what they can do at any time. (Incidentally, this behaviour works for Chrome because it is designed *very* differently.)
FWIW, "close app on closing last tab" doesn't work too great for Chromium either and we (Google) have bugs on file about considering changing that behavior to Firefox' (previous) behavior, which I've always found far more sane.
(In reply to comment #56) > FWIW, "close app on closing last tab" doesn't work too great for Chromium > either and we (Google) have bugs on file about considering changing that > behavior to Firefox' (previous) behavior, which I've always found far more > sane. Peter, do you have any links handy so we can see what others are suggesting for Chrome/Chromium?
There are multiple issues with this. 1) Some users, however small minority, use Linux. GNOME in particular has a policy of presenting an orthogonal user interface. The window manager or compositor already have fancy ways of flipping through open windows or arranging them in an arbitrary manner. So, what is the point of trying to duplicate this inside the browser? The Ctrl+Tab preview is just a dumbed down version of Alt+Tab, which the system provides and which is therefore consistent. If nothing else, at least when a GNOME platform is detected I think Firefox should default to no tab strip and opening new pages in a new window. However, I really don't understand why tabbed browsing was added at all, as the windowing systems already provided a richer and more refined way to deal with multiple open documents, be they web pages or a mixture of anything. 2) About closing the browser when closing the last tab, this is an age-old design mistake. Look at MS Word, it doesn't close when you close the last document. Look at Opera, same thing. Emacs? And yes it's really annoying in Chrome, I assume it's an unintended behaviour there as Google's team got most other UI design right, for example hiding the Status Bar. What's the point again of taking yet another twenty-someting pixels of vertical screen space just to show "Done", anyway? The obvious solution is to restore how Firefox worked before.
(In reply to comment #57) > Peter, do you have any links handy so we can see what others are suggesting for > Chrome/Chromium? No, but the short summary is "when closing the last tab, replace with a New Tab". It is not clear whether this only applies to the last open browser window, or to all windows. Also, not everyone on the team agrees this is a good idea. We are not considering "hide the tabstrip area when only one tab is present".
[Off-topic] So what's the point of tabs? Especially in Chrome which is a platform for web-based apps, it's natural that your word processor and your mail client runs in different windows. You might even want to display them side-by-side. Can't do it with tabs. People naturally open new browser windows for new tasks with IE6, it would be interesting to know exactly how many still do this with IE7 but I suspect a lot. The only time I find myself using tabs is when a page contains a lot of outlinks which I intend to read. So I open them in tabs, read and close the tabs one-by-one and this gets me back to the original page. Basically, I use tabs as a workaround for bad site design. A more helpful browser support for this workflow would be to let the user mark links for reading, then "start reading" (loads first link), then display an option link "read next" (loads next link) and "return to origin", and at the last marked-to-read link, return is probably the only sensible option. There are still bookmarks for marking pages for reading LATER. Opera's "fast-forward" and "rewind" come somewhat close, but try to overgeneralize and therefore often don't give you quite what you want. ANYWAYS, I don't think tabbed browsing should be made easy to discover just because Firefox supports it. Users, ordinary non-early-adopter users simply don't want or need tabs.
As I think it's not entirely appropriate to discuss this issue in this bug entry, here's a plug of my anti-tab rant: http://grfgguvf.blogspot.com/2008/09/tabbed-browsing-sucks-bay-leaves.html If you have any opinions then direct them there in the comments maybe..
Of some concern is the fact this change breaks Windows user interface guidelines as laid out by Microsoft (I can not speak for other operating systems). CTRL+F4 should only close child windows, not the parents / applications (ATL+F4 is for closing apps). See this URL for details: http://msdn.microsoft.com/en-us/library/ms971323.aspx#atg_keyboardshortcuts_windows_shortcut_keys Excerpt from the above referenced page: Navigation and Window Controls Shortcut Keys Press To CTRL+F4 Close the active document in applications that allow you to have multiple documents open simultaneously. ALT+F4 Close the active item, or quit the active application.
> CTRL+F4 should only close child windows, not the parents / applications (ATL+F4 > is for closing apps). > http://msdn.microsoft.com/en-us/library/ms971323.aspx#atg_keyboardshortcuts_windows_shortcut_keys That document does not specify how far you're allowed to tear down ui and processes made (arguably; some care about chrome and processes beyond their support of presently viewing a document, others don't) redundant by closing a document using ctrl-f4. Having in alt-f4 the means to do that teardown along with several contained documents doesn't quite imply it either. Convention is another thing and important, but reading that document to say that a window or application must never close as a side-effect of ctrl-f4 is overreaching.
Depends on: 456382
(In reply to comment #50) > Maybe make it so that when the last tab is closed, it becomes empty, > and if it's closed again, only then close the browser window. This really seems a good idea.
Depends on: 456405
(In reply to comment #50) > Maybe make it so that when the last tab is closed, it becomes empty, > and if it's closed again, only then close the browser window. I agree with this idea as well. - No additional code logic complexity as landed by https://bugzilla.mozilla.org/show_bug.cgi?id=455852 (including the part that it's a hidden pref) - Good compromise for the "easy discoverability" and "existing users" camp
Depends on: 456425
Flags: in-litmus?
Comment 1 items verified fixed using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre
Status: RESOLVED → VERIFIED
Flags: blocking-firefox3.1?
Depends on: 462673
No longer depends on: 462673
Depends on: 501290
(I hope this is the right place for this comment) The new behavior of closing the last tab in FF 3.5 is really horrible. Previously, there was UI consistency - there's always a close button on every tab, and it always behaves the same (regardless of whether it's the last tab or not - no big surprises like shutting the entire browser down). The new functionality is a step backwards in usability in more than one way: 1. lack of consistency in display (the close button doesn't appear equally on all tabs, as it's missing on the last open tab). 2. lack of consistency in behavior (closing the last tab, with ctrl-W for example, behaves differently than closing other tabs) 3. slow down in usage - previously you could press ctrl-W repeatedly to quickly close all open tabs and prepare for a new session. currently this will result in the browser closing, and having to manually reopen it, which takes more time and effort. or, alternatively, slow down significantly the ctrl-W sequence to be careful to stop when there's one tab left. 4. less user control - previously, the user could tell FF what he wants to do. press either the window's close button or the tab's close button. press ctrl-w or alt-f4. same effort, with predictable user-chosen behavior. the new behavior takes that freedom away, and tries to second-guess the user's intention instead of just letting him select what he wants to be done. So, there are several serious usability issues created by the changed behavior, while there's no gain - the previous behavior allowed the user to choose the desired behavior with no additional effort and far better consistency. I really don't get how this came to be... here's my vote for undoing this and going back to the previous tab-closing behavior.
I fully agree with amichai2@amichais.net . I vote for undoing this annoying "new behaviour". Another argument: I use Linux Gnome with many virtual desktops. Sometimes I want to have got Firefox windows (with an empty tab) on every desktop (for quick access to Google or my bookmarks). Please consider that.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: