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.

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?

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...

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

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.

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.

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).

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?

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.

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"

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

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

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.

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

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

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

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.

--> enhancement

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.

taking QA contact, sorry about the bugspam

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

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

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.

Fixed it is then.

verified with 2003010 W2K build.

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