Closed Bug 347844 Opened 18 years ago Closed 18 years ago

Toolbars bloated and can no longer be easily configured

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: Sokraates, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060807 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060807 BonEcho/2.0b1

Starting with the "Search"-button being linked to the search-bar, new buttons have been forced upon the user without being removable. 

Today we have 3 exaples of this trend:
1) The "Search"-button is linked to the search-bar. You can't remove one without the other.
2) The "Go"-button is linked to the location-bar. You can't remove one without the other.
3) The "List All Tabs"-button can not be removed at all.

Reproducible: Always

Steps to Reproduce:
1. Right-click on the toolbar. 
2. Select customize
3. Drag the "Go" (or "Search")-Button to the newly opened window.

Actual Results:  
The "Go"- or "Search"-buttons also remove the location- or search-bar.

Expected Results:  
Removing the button should not result in the removal of the attached bar.

Generally it is known, that all the toolbars can be configured using CSS. So even these problems could be solved. So the real problem is the principle behind these changes: forcing new buttons on users (that is: creating bloat and taking away space in the already crowded toolbars), without giving them the option to easily remove them.

Requiring the usage of CSS or about:config for some changes is valid. But toolbars should be easily configurable. That's the reason why the "Customize"-option was introduced in the first place.

So here's the solution:
1) Each and every button and bar should be removable by itself. Never link two buttons or a button with a bar.

2) Each and every button and bar should be removable in the first place. Introduce new features involving new buttons or toolbars by turning them on by default. But allow the user to remove them separately.

3) If one button does not make much sense without another button or bar, Firefox may notify the user and recommend to remove or keep both. But generally, a bar is always usable without a button (there's the "enter"-key, which next to every user knows by now).
Bug 347754 covers part of the issue here.
Depends on: 347754
(In reply to comment #1)
> Bug 347754 covers part of the issue here.
> 

I am well aware that some bugs are already dealing with one of the listed examples. 

I've created this bug because of the principle behind them. If every button was removable and removable on its own (as it was before), those bugs wouldn't be filed. 
(In reply to comment #0)
> 3) The "List All Tabs"-button can not be removed at all.

Good point, I never really thought about this. Since the scroll buttons are there to stay, the "all tabs" button isn't absolutely indispensable.

Admittedly, removing it is probably an extension's task. I don't think many users want this and the tab strip isn't a toolbar anyway.
(In reply to comment #3)
> (In reply to comment #0)
> > 3) The "List All Tabs"-button can not be removed at all.
> 
> Good point, I never really thought about this. Since the scroll buttons are
> there to stay, the "all tabs" button isn't absolutely indispensable.
> 
> Admittedly, removing it is probably an extension's task. I don't think many
> users want this and the tab strip isn't a toolbar anyway.
> 
The tab-bar may be something special, but I sincerely don't understand, why a new button is needed there. It's crammed already (see the discussions on adding a close-button on each tab).

The "List All Tabs"-button can be removed using CSS, so an extension will deffinitely do the trick. Still I don't understand why a user should wait for an extension. Extensions should (usually) add features/buttons, not remove them. We already have the "customize"-option, so it would make sense to allow customization of every button.

(In reply to comment #4)
> The tab-bar may be something special, but I sincerely don't understand, why a
> new button is needed there.

See bug 318168 and bug 343251.

> Extensions should (usually) add features/buttons, not remove them.

Adding the ability to remove something extends the browser.

> We already have the "customize"-option

Yes, for toolbars.
Getting my vote on this part:

"Toolbars can no longer be easily configured"
(In reply to comment #5)
> (In reply to comment #4)
> > We already have the "customize"-option
> 
> Yes, for toolbars.

Exactly.  This request is equally reasonable to a request to be able to "customize->remove the close button from the tab strip" in Fx 1.0/1.5.  That's a good feature--for an extension.  Otherwise, the tab strip is not a toolbar.

I'm not trying to dismiss your POV though.  Perhaps the tab strip should become the "Tab Toolbar" and be toggleable on and off, and customizable, in the same way other toolbars are.  Currently it would have a large flexible "Tabs" section, and an "All Tabs" button at the end.  Maybe "New Tab", "Close Tab", etc. buttons qould be other choices in the menu o' buttons of what could go here.

If that's really worth pursuing, it's probably worth pursuing as a separate bug that blocks this bug.
As far as the "List All Tabs"-button is concerned, I must admit, that I was obviously guided by a misconception.

I concidered the tab-bar a toolbar like the bookmark- or navigation-toolbar which seems to be incorrect. So if the tab-bar can only be changed/customized with serious additional effort, then such a feature has to be left to extension.

For the regular toolbars, the bug remains valid, since we have customizability, the famous "Go"-button already was removable, so adding this "feature" back shouldn't be any problem.
Depends on: 347930
(In reply to comment #8)
> I concidered the tab-bar a toolbar like the bookmark- or navigation-toolbar
> which seems to be incorrect. So if the tab-bar can only be changed/customized
> with serious additional effort, then such a feature has to be left to
> extension.

Filed bug 347930 on changing the tab strip to a toolbar.
No longer depends on: 347930
should change Hardware -> All and OS -> All

> 1) The "Search"-button is linked to the search-bar. You can't remove one
> without the other.

I kinda like the way the search button is within the search box. We /could/ have 2 search boxes - one with the search button and one without it... Otherwise we could remove the button from inside the search box and have it outside it..

Or we could make the actual search and location boxes customizable - right click on them and you get a 'customize' entry in the menu and then a dialog comes up with some options (or it could be the same as the toolbar customize dialog, where you can drag things on and off the search/location box).
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #10)
> I kinda like the way the search button is within the search box.

The button isn't within the search box, actually.
(In reply to comment #11)
> (In reply to comment #10)
> > I kinda like the way the search button is within the search box.
> 
> The button isn't within the search box, actually.
> 

Not anymore it isn't, I only updated now, ignore that part of my comment.
I don't foresee anything being fixed as a direct result of this bug. This was a meta/advocacy bug from the start and it appears to be continuing down that path.
There are already separate bugs filed for each and every point brought up here - several of which I'm personally working on. 

This bug is far too broad and is already covered in its entirety by those filed individually. 
-> Invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
No longer depends on: 347754
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.