If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Easy discoverability of Tabbed Browsing for new users

VERIFIED FIXED in Firefox 3.1b1

Status

()

Firefox
General
P4
normal
VERIFIED FIXED
10 years ago
7 years ago

People

(Reporter: ronin.achilles, Assigned: dao)

Tracking

Trunk
Firefox 3.1b1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 -
wanted-firefox3 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 5 obsolete attachments)

(Reporter)

Description

10 years ago
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.
(Reporter)

Updated

10 years ago
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

Updated

10 years ago
Flags: blocking-firefox3? → blocking-firefox3+

Updated

10 years ago
Target Milestone: --- → Firefox 3 M9
moving out bugs that don't need to block b1
Target Milestone: Firefox 3 M9 → Firefox 3 M10

Updated

10 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M11
(Assignee)

Comment 3

10 years ago
Created attachment 287842 [details] [diff] [review]
patch
Attachment #287842 - Flags: review?(mconnor)
(Assignee)

Comment 4

10 years ago
Created attachment 287843 [details] [diff] [review]
patch v2

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-
(Assignee)

Comment 6

10 years ago
Created attachment 287852 [details] [diff] [review]
patch v3
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+
(Assignee)

Comment 8

10 years ago
So is this ready to land or is there something to wait for?
(Assignee)

Updated

10 years ago
Attachment #287852 - Flags: review?(neil)
(Assignee)

Updated

10 years ago
OS: Windows Vista → All
Hardware: PC → All
Version: unspecified → Trunk

Comment 9

10 years ago
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+
(Assignee)

Comment 10

10 years ago
Created attachment 287920 [details] [diff] [review]
for check-in
Attachment #287852 - Attachment is obsolete: true
(Assignee)

Comment 11

10 years ago
taking the bug officially
Assignee: mconnor → dao
Keywords: checkin-needed
(Assignee)

Updated

10 years ago
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
Last Resolved: 10 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 → ---

Comment 14

10 years ago
(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.
(Assignee)

Comment 15

10 years ago
(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.

Updated

10 years ago
Priority: -- → P2
(Assignee)

Comment 16

10 years ago
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.?
(Assignee)

Comment 18

10 years ago
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.
(Assignee)

Comment 19

10 years ago
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...
(Assignee)

Updated

10 years ago
Depends on: 387345
Keywords: checkin-needed
Whiteboard: [has patch][has reviews]
(Assignee)

Updated

10 years ago
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
(Assignee)

Updated

10 years ago
Attachment #287920 - Attachment description: for check-in → for check-in (checked in)
(Assignee)

Comment 23

10 years ago
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

Comment 25

10 years ago
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.

Comment 26

10 years ago
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...)

Updated

10 years ago
Duplicate of this bug: 345811

Updated

10 years ago
Duplicate of this bug: 406323
(Reporter)

Comment 29

10 years ago
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.
(Assignee)

Updated

10 years ago
Target Milestone: Firefox 3 M10 → ---
(Assignee)

Updated

10 years ago
Whiteboard: [has patch][has reviews] → [has patch][has reviews][wontfix?]
(Assignee)

Comment 30

10 years ago
Created attachment 300107 [details] [diff] [review]
updated to trunk
Attachment #287920 - Attachment is obsolete: true

Comment 31

10 years ago
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

Comment 33

10 years ago
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.

Comment 34

10 years ago
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.

Comment 35

10 years ago
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

Comment 36

10 years ago
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+

Updated

10 years ago
Duplicate of this bug: 426345
(Assignee)

Updated

10 years ago
Assignee: dao → nobody
(Reporter)

Comment 39

9 years ago
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)
(Reporter)

Updated

9 years ago
Flags: blocking-firefox3.1?

Comment 40

9 years ago
(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
(Assignee)

Comment 41

9 years ago
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
Last Resolved: 10 years ago9 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews][wontfix?]
Target Milestone: --- → Firefox 3.1b1
(Assignee)

Comment 42

9 years ago
Created attachment 339069 [details] [diff] [review]
updated, landed patch
Attachment #300107 - Attachment is obsolete: true

Comment 43

9 years ago
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".
(Assignee)

Comment 44

9 years ago
(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.
(Assignee)

Updated

9 years ago
Blocks: 455756

Comment 45

9 years ago
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.
(Assignee)

Comment 46

9 years ago
(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.

Comment 47

9 years ago
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...

Updated

9 years ago
Depends on: 455852
(Assignee)

Updated

9 years ago
Depends on: 455864
(Assignee)

Updated

9 years ago
Blocks: 400398

Comment 48

9 years ago
OT: I just hate how this affects my workflow right now =(

Comment 49

9 years ago
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?

Comment 50

9 years ago
(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.

Comment 51

9 years ago
(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?

Updated

9 years ago
Depends on: 456002
(Assignee)

Updated

9 years ago
Depends on: 455990

Comment 52

9 years ago
Created attachment 339466 [details]
Windows Live Toolbar Tabs

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

Comment 53

9 years ago
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.

Comment 54

9 years ago
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.

Comment 55

9 years ago
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.)

Comment 56

9 years ago
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.

Comment 57

9 years ago
(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?

Comment 58

9 years ago
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.

Comment 59

9 years ago
(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".

Comment 60

9 years ago
[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.

Comment 61

9 years ago
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..

Comment 62

9 years ago
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.

Updated

9 years ago
Depends on: 456405

Comment 65

9 years ago
(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?

Updated

9 years ago
Duplicate of this bug: 457783
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

Updated

9 years ago
Flags: blocking-firefox3.1?
https://litmus.mozilla.org/show_test.cgi?id=7431 and https://litmus.mozilla.org/show_test.cgi?id=7432 added to Litmus.
Flags: in-litmus? → in-litmus+
(Assignee)

Updated

9 years ago
Depends on: 462673
(Assignee)

Updated

9 years ago
No longer depends on: 462673

Updated

9 years ago
Duplicate of this bug: 489003
Duplicate of this bug: 490453
Duplicate of this bug: 490501
(Assignee)

Updated

8 years ago
Duplicate of this bug: 495904
(Assignee)

Updated

8 years ago
Depends on: 501290

Comment 73

8 years ago
(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.

Comment 74

8 years ago
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.