Home button should always stay small on the secondary toolbar in the main browser window

RESOLVED WORKSFORME

Status

SeaMonkey
UI Design
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: rsx11m, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [workaround: comment #3/#4])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
As observed while testing for bug 849359, but equally applies to both themes.

Steps to reproduce:
 - Open a browser window
 - by default, top toolbar has large icons, bottom toolbar has small icons
 - right-click on top toolbar and select "Customize"
 - check the "Use Small Icons" box
 - upper toolbar gets small toolbar icons
 - uncheck the "Use Small Icons" box
 - upper toolbar gets large toolbar icons (expected)
 - lower toolbar gets large toolbar icons too (unexpected)
 - unable to get back to the default (upper=large, lower=small)

The expectation is that the Home button (and probably any other buttons one may drag there) stays small regardless of the setting of the upper toolbar, also given that the Bookmarks and Most Visited icons stay small as well.

This has been in there for a while, I can reproduce back to 2.0.14. I would expect that someone has filed this already, but cannot find anything on it.
(Reporter)

Comment 1

5 years ago
Created attachment 729330 [details]
Screenshot large-small-large

Shown in 2.0.14 on Windows 7, still reproducible.
(Reporter)

Comment 2

5 years ago
So, suite/browser/navigator.xul defines <toolbar id="PersonalToolbar"> with iconsize="small" and defaulticonsize="small" attributes. Thus, clicking on the "Restore Default Set" button also resets the lower toolbar to small icons, but that's a bit of a brute-force approach to get the expected sizes again.

Apparently the iconsize="small" doesn't persist when toggling "Use Small Icons" thus also affecting the lower toolbar, and it changes size with the upper one.

I found Toolkit bug 407899 separating the icon sizes per toolbar, apparently to specifically handle that case for the main browser toolbars. One could work around the problem by defining separate rules for #PersonalToolbar > #home-button in addition to the toolbar[iconsize="small"] > #home-button rules, but that would have to be done for all buttons and all themes. So, solving the problem at the toolbar level itself seems to be the preferable approach.

Comment 3

5 years ago
Try this:

Right click on a blank spot on the PersonalToolbar (or even on the home button)
Settings for this toolbar -> Use default settings.
(Reporter)

Comment 4

5 years ago
Uh, this works but is hard to discover (well, less hard; right-clicking on the Home button itself indeed works already). There is even a menuitem "Use small icons" now that I found that menu, thus you don't even need to reset the toolbar to its default.

I'm wondering why the two toolbars are tied to each other in the first place. Ok, they are in the same toolbox so that you can move items from one toolbar to the other, but I'd expect settings like text position or icon sizes to be specific to the toolbar that I selected to customize and not to be applied to all toolbars in the toolbox.
Whiteboard: [workaround: comment #3/#4]

Comment 5

5 years ago
> Uh, this works but is hard to discover
User-doc-requested.

The toolkit customize toolbar function applies globally to all toolbars (See the Firefox behaviour). When I implemented Customizable Toolbars in SeaMonkey I ran into problems with the Home button (as you noticed). So I added some SeaMonkey specific functionality to allow each toolbar to have their own settings. Some bits were eventually added to Toolit because Firefox needed it. Some but not all so the UI to configure each toolbar separately remains SeaMonkey only.
(Reporter)

Comment 6

5 years ago
Ok, if this is the desired behavior, I'm fine with a WFM for this specific bug. Thus, it seems to come down to properly documenting this in Help, which currently doesn't have a "Customize Toolbar" description.
(Reporter)

Updated

5 years ago
Blocks: 536257
(Reporter)

Comment 7

5 years ago
(In reply to Philip Chee from comment #5)
> > Uh, this works but is hard to discover
> User-doc-requested.

Bug 536257.

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.