268198 - Improving firefox's tabbed browsing architecture (not just UI improvements)

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, enhancement)

Description

[Yuan Qi]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2

This bug gives some suggestions to how firefox could improve its underlying
architecture in tabbed browsing for Firefox 1.1.

First of all, I think firefox should implement two modes on the UI level, tabbed
browsing mode and traditional browsing mode (aka. new window mode). User just
select their preferred mode and the appropriate settings will be selected. This
simplies the tabbed browsing preferences in "Options.../Advanced" and make it
easier for novice users.

On the underlying level, we should implement the following preferences
Browser.open.opennewfor.bookmarks (this option allies to the bookmarks sidebar,
the bookmarks toolbar and the bookmarks menu)
Browser.open.opennewfor.history (this option applies to the history sidebar and
the go menu)
Browser.open.opennewfor.DDEcall (this option should also apply to the firefox
help system and the extensions manager)
Browser.open.opennewfor.externallink
Browser.open.opennewfor.home
Browser.open.opennewfor.javascriptcall (if false is selected, popups will be
opened in the current tab)
Browser.open.opennewfor.middleclick (shift+click and ctrl+click should dod the
same thing under this: either they open a new winodw or a new tab)

Browser.open.opennewtab
Browser.open.openinforeground (this option also applies to new window mode. It
specifies whether or not the newly opened window will receive focus)

I am sure this bug duplicates the ideas of other bugs and some of the ideas had
already been implemented. It would be nice if these bugs are cosolidated into
one meta bug to be resolved.

I believe the proposed changes will make fx's architecture less confusing and
will solve the tab browsing problems once and for all. 

Reproducible: Always
Steps to Reproduce:

Comment 1

[Mike Connor [:mconnor]]

This is pretty incoherent, since you're not really explaining why these prefs
are necessary.  

I guess some of them would open a new tab on just a click?  That seems pointless
when click modifiers work nearly everywhere now, so you can control where things
open.  There are extensions out there that do some of this already, but
something this complex and potentially confusing will not be implemented as a
core feature.

Note that part of this seems to want to make Shift-Click and Ctrl-Click
identical, which ignores the entire point of supporting both.  Our current
implementation is very powerful and flexible, and doesn't require a large number
of preferences.  In fact, using key modifiers you have complete control over
foreground/background tabs or new windows, without changing any prefs. It just
works, instead of requiring 15-20 prefs, which is how we designed it.

Comment 2

[Yuan Qi]

First of all, I am sorry for not explaining myself well.

The reason for implementing these prefs is because right now, the mouse
modifiers are not exactly convinient (especially the shift+click and ctrl+click,
they use both keyboard and mouse and are more awkward than middleclicking and
drag and drop. Middle clicking is acceptable, except it's not available on all
computer, in particular Mac users and clicking on a wheel is not exactly
comfortable) 

Besides, most novice users do not know about middle clicking (according to the
Gnome HIG 2.0, the usability team even claimed that most novice users don't even
know about context menus, let along middle clicking), the only way for them to
truly discover the power of firefox's tabbed browsing is to enable the feature
by default (and open new tabs with left clicks).

In addition to that, the current shift+clicking, ctrl+clicking and middling
clicking behaviour do not fit into the Gnome HIG.

Lastly, it seems extensions do not exactly work well with regard to tabbed
browsing behaviours. TBE is a very good example: it is makes firefox slow and
unstable.

The pref suggested here allows users to open new tab/windows (depending on the
Browser.open.opennewtab pref) when they left click their bookmarks/history, type
in urlbar/searchbar, when javascript opens a new window or when external program
sends in a call. 

These complex pref are *NOT* implemented on hte UI level. On the Option
dialogue, there is only one option: tabbed brwosing (where bookmarks, history,
urlbar, searchbar, js call and DDE call will all result a new tab opened) or
traditional browsing (IE behaviour: only DDE call and js call results in new
window) This should keep novice users from being confused (the options in the
advanced tab in the options tab is confusing enough in its present state)

As for the mouse modifiers, they are still supported, shift+click and ctrl+click
still work the same way as before. However, in this implementation, their
importance has been reduced to mere shortcuts (which is what they are supposed
to be, shortcuts) Users do not need them to make the most out of the tabbed
browsing functionalities, they are used to handle special cases.

I hope I have explained myself well, if not, I can further clarify my points.
Personally, I think usability should be a priority of firefox, since it is
marketed not only toward technical users, but also novice users. So please
consider these points carefully.

Thank you.

Comment 3

[Yuan Qi]

Also, I don't think the complexity of the underlying architecture of firefox has
anything to do with UI simplicity. Gnome DE is a very complex set of programs
(just look at GConf for the complexity of its prefs.) Yet, the options it
reveals to the user are very simple and easy to understand. I am not suggesting
that firefox should add 10+ options to the Options dialogue. These settings are
supposed to be hidden settings for powerusers, system admins and distro package
maintainers.

Comment 4

[Mike Connor [:mconnor]]

file individual bugs for individual issues.  Filing a long-winded bug is not
productive.  Also, unless you have some compelling argument that was not in the
original report, reopening is improper.  So is filing the same bug again.

Comment 5

[Mike Connor [:mconnor]]

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