191746 - Bring back some tab preferences

Status: VERIFIED FIXED

(Firefox :: Settings UI, enhancement)

Description

[David P James]

The recent changes to the Options panel (see bug 191524) have removed most of
the tabbed browsing preferences. I think that this is a mistake. One of the
greatest strengths of a browser like Phoenix is tabbed browsing, yet in its
current form a new user is less likely to be able to discover and use this feature.

Suggestions to rectify this:
(1) The preference to not show the tab bar when only one tab is open could be
set to false by default. This would at least alert a new user to the possibility
that tabs exist
(2) The old tabbed browsing preferences could be returned (as some of them used
to mention how to open new tabs)

The fact that TBE exists is not relevant when the user doesn't have a notion
that tabs exist in the first place or what they are. For example, I first
discoved tabs in Mozilla through (2) above as one of the prefs mentioned how to
activate them, and tried it out.

Comment 1

[Chu Alan "sprite"]

tab options from mozilla :-

== Tab Display ==
[X] Hide the tab bar when only one tab is open
[X] Load links in the background <-- we have this already

== Open tabs instead of windows for ==
[X] Middle-click, Control+click or Control+Enter on links in a Web page
[X] Control+Enter in the Location bar

so we should put these three controls to General -> Windows and Tabs?

Comment 2

[Chu Alan "sprite"]

Attachment: first trial to put controls back

i think the auto hide pref should be there, but is the two 'open tab for...'
necessary?

P.S. Control+Click in urlbar = open new tab does not work anymore...

Comment 3

[Chu Alan "sprite"]

sorry... just want to add this patch does not contain accesskey, may be i will
add the accesskey later in the accesskey bug.

Comment 4

[David P James]

Alt+Enter has replaced Ctrl+Enter for opening the contents of the location bar
in a new tab (Ctrl+Enter now does the IEish thing of prepending "www." and
appending ".com").

The "Open tabs..." prefs aren't strictly necessary, but their presence has an
informative value as well. A blurb like "Phoenix opens a new tab from a
Middle-click, Control+click or Control+Enter on links in a Web page and from
Alt+Enter in the URL bar" would do it as well.

Comment 5

[Chu Alan "sprite"]

um... I think omitting the "Open tabs for..." prefs will make the pref window
cleaner...
(may be putting them in seperate window, like Advanced JavaScript pref?)

,---- Windows and Tabs -------------------------------.
| [X] Hide the tab bar when only one tab is open      |
| [X] Open links in background                        |
|                                       [Advanced...] |
`-----------------------------------------------------' 

,-----------------------------------------------.
| Advanced tab options                          |
+-----------------------------------------------+
| Load new tabs when:                           |
| ,-------------------------------------------. |
| | [X] Middle-click, Control+click or        | |
| |     Control+Enter on links in a Web page  | |
| | [X] Control+Enter in the Location bar     | |
| `-------------------------------------------' |
`-----------------------------------------------'

Ben:
How is your thought? I will be glad to provide a patch for this after you have
made a decision if you are busying on other bug fixes.

Comment 6

[Jake]

When you are at it please at a switch that would allow the user to choose wether
bookmarks (and toolbar items) should open in the background (as do links on
normal pages).

And you could add a pref that overrules any new window (just like
user_pref("browser.block.target_new_window", true); does), but it's not really
important (caus it can be done by hand). It does give ultimate user control
(middle-click would be tab, in background (or foreground, depending on
userpref), left-click would be tab in foreground).

Comment 7

[Mike Connor [:mconnor]]

First I expect the patch above is obsolete with the new preferences dialog. 
This is something that I'd be interested in doing if no one else is working on it.

Intuitively, this really belongs with Web Features, but I'd have to convert the
popup whitelist to a second dialog window to make room there.  Any thoughts on
this change?

Comment 8

[David P James]

I came to a similar conclusion myself - that tab settings ought to be in Web
Features and that the pop-up whitelist should be a button-launched dialog, as it
is in Mozilla I believe. As it happens, someone else has thought of it as well;
see bug 200729.

Comment 9

[Mike Connor [:mconnor]]

Attachment: screenshot of additional prefs dialog

need to make a working diff before I attach the patch, this is a screenshot of
what this looks like as of now.  The prefs are based off the ones mentioned
originally, although some no longer have any effect in Firebird and I have
edited/removed these as needed.

A couple additional changes I would like to make for clarity:
"Windows and Tabs" to the more accurate "Tabbed Browsing" heading 
"Open Links in Background" to "Open New Tabs in Background"

Comment 10

[Mike Connor [:mconnor]]

Attachment: patch for advanced tab options window

I'm new to this, not 100% on the diff being the way it should be

Comment 11

[Mike Connor [:mconnor]]

*** Bug 213095 has been marked as a duplicate of this bug. ***

Comment 12

[Neil Parks]

Please see comment #1 for bug #213095.  To summarize:  With all versions of
Phoenix and Firebird through July 2, I was able to use the extension Tabbrowser
Preferences to have new tabs open on my home page.  The optimized July 17
Firebird does not honor this preference even with the extension installed.

Comment 13

[Simon Paquet [:sipaq]]

*** Bug 213522 has been marked as a duplicate of this bug. ***

Comment 14

[Neil Parks]

Followup to my comment #12:  The preference is working properly for me using
Optimized 7/21.

Comment 15

[David P James]

Mike,

I just attempted to apply your patch and it seems to have caused the Options
Dialog to lose the ability to save any changes. Moreover, pressing the Advanced
Tab Options button locks up the dialog and the browser (on Linux at least).

Comment 16

[Mike Connor [:mconnor]]

Comment on attachment 126245 [details] [diff] [review]
patch for advanced tab options window

Cancelling the review request.	For all I know this patch is suffering from
bitrot. :)  I'm also not sure the diff method is right for the new files
needed, so I'm going to withdraw it until ben issues some clear indication of
where he's taking the prefs dialog (I know there's changes coming such as
Helped Apps)

Comment 17

[David P James]

Attachment: Tweaking of Mike's patch

You were just missing a couple of ++ in your javascript function. As for adding
new files to CVS, that is a major PITA. cvs add would not allow me to add files
to my OWN repository! So I had to employ this rather sad method of appending a
couple of diffs against /dev/null to get it into the patch. Anyway, I also
added a short blurb about Alt+Enter so that we can avoid a whole slew of
"Ctrl+Enter does funny things" bug reports from migrating SeaMonkey users. Plus
it has an informative value as well. Like you, I'm going to hold off on the
review though until Ben does his thing.

Comment 18

[Mike Connor [:mconnor]]

--> enhancement

Comment 19

[Mike Connor [:mconnor]]

Bug 177506 brought up a good point, if the "hide tab bar with one tab open" pref
is changed, we need to check for the current state of the tab bar and
hide/unhide as appropriate (I can do this, I just don't want to invest more time
into this patch unless its going in).  If we do want to go ahead and add these
options back in, that needs to be added as well.

Comment 20

[Mike Connor [:mconnor]]

taking QA contact, sorry about the bugspam

Comment 21

[Simon Paquet [:sipaq]]

*** Bug 214288 has been marked as a duplicate of this bug. ***

Comment 22

[Pham]

I think you need a new patch because the tab prefs is in Advanced now

Comment 23

[David P James]

The following were the prefs included in Mike's patch. By default, all are set
to "true" in Firebird.

browser.tabs.loadFolderAndReplace
browser.tabs.opentabfor.middleclick
browser.tabs.autoHide

The last has now been included in the new Advanced pane (along with
browser.tabs.loadInBackground, which is also set to "true" by default). I
suspect that autoHide was the one that most people wanted to see included in the
UI. Personally, I set the first of the 3 above to "false", but I don't really
use that functionality much so its lack of presence doesn't bother me much.

What does bother me a bit is how loading links in the background is described in
the new UI - there is no mention of it being a tab/window pref and from the way
it is written it sounds as if the pref applies to regular clicks and not Ctrl
and middle clicks. *We* know that's not the case, but think about this from the
PoV of someone new to FB/Moz... the previous setup was superior in that regard
IMO. Something like what I wrote in comment #4 would still be helpful I think.

But by and large, I'm willing to resolve this bug as FIXED. I'll resolve it as
such in a day's time if no one objects.

Pham: when you make a comment like that please add yourself to the CC: list. Not
only that, there was no need for that comment anyway - we all knew about the
change and it was just a matter of time before one of us did something about
this bug.

Comment 24

[David P James]

Fixed it is then.

Comment 25

[Simon Paquet [:sipaq]]

verified with 2003010 W2K build.

Comment 26

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change