Boldfaced search engine menu tems are one point size too small

RESOLVED FIXED in Camino1.6

Status

Camino Graveyard
Toolbars & Menus
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Mark Mentovai, Assigned: Stuart Morgan)

Tracking

({fixed1.8.1.13})

1.8 Branch
Camino1.6
All
Mac OS X
fixed1.8.1.13
Bug Flags:
camino1.6b3 -

Details

Attachments

(5 attachments)

(Reporter)

Description

10 years ago
This may be Leopard-specific, but the boldfaced items in the search engine menu and search engine editor window are displayed one point size too small.  Items in the menu that are displayed with ordinary non-attributed strings are displayed in what appears to be Lucida Grande 14.  The boldfaced items we're displaying with attributed strings use Lucida Grande Bold 13.  This is what we get from [NSFont boldSystemFontOfSize:0]; note that [NSFont menuFontOfSize:0] returns Lucida Grande 13, and [NSFont systemFontSize] returns 13.

I actually hate the boldfacing.  It looks so out of place in a Mac menu.  If we need these items to stand out in the menu, maybe we could make them mixed-state menu items.  For the editor, we shouldn't use boldfacing, we should display the selected default search engine with a checkmark.
(Reporter)

Comment 1

10 years ago
Created attachment 297016 [details]
Now you see it
In the menu, the one-point-too-small problem persists as far back as 10.3.  In the editor, they don't look smaller to me on either 10.3.9 or 10.5.1.

If we go with a checkmark in the editor, will the two different meanings (currently selected engine, in the menu, and default engine, in the editor) confuse people?
Component: General → Toolbars & Menus
QA Contact: general → toolbars

Comment 3

10 years ago
I don't like the idea of a checkmark meaning two different things either. What's wrong with bold in the editor?
(Reporter)

Comment 4

10 years ago
You're right, the items are sized consistently in the editor - I was comparing the interior space in a bold "G" to a not-so-bold "G," which wasn't the right way to compare.

I thought that the default in the editor WAS the currently selected engine in the menu.  Is there something I'm missing?  Certainly, when I say "Make Default" in the editor, it changes the currently selected engine in the menu.  (Unless I've got multiple windows open, then it changes the selected engine in the first window only - this seems buggy.)
Summary: Boldfaced search engine menu items and editor items are one point size too small → Boldfaced search engine menu tems are one point size too small

Comment 5

10 years ago
(In reply to comment #4)

> I thought that the default in the editor WAS the currently selected engine in
> the menu.  Is there something I'm missing?  

We defined the default search engine as the one chosen when a new window is opened.  The actively selected engine in a window can be something other than the default, and choosing other engines in a WebSearchField has no effect on other windows.

> Certainly, when I say "Make
> Default" in the editor, it changes the currently selected engine in the menu. 
> (Unless I've got multiple windows open, then it changes the selected engine in
> the first window only - this seems buggy.)

We put some thought into this behavior over on bug 201723 in comments 42 and 43, so there is actually some logic behind the process...

When changing default engines via the editor, using "Make Default," any windows whose WebSearchField had their active engine selection set to what was previously the default will be updated to select the new default.  The active engine selection is not changed in windows where the user switched away from the default.  

So, put another way, if you were using the default engine, your selection follows whatever the current default is.  If you switched to another engine, your selection stays the same.
I don't know if we want to fix this for 1.6 or not; we should make a decision quickly, though.
Flags: camino1.6b3?
(Assignee)

Comment 7

10 years ago
No nib changes are necessary, so -'ing for b3. We should fix this for 1.6 though.
Flags: camino1.6b3? → camino1.6b3-
Target Milestone: --- → Camino1.6
(Assignee)

Comment 8

10 years ago
Created attachment 305772 [details] [diff] [review]
bold fix

Option 1: Just fix the bolding by making the system give us the right font.
Assignee: nobody → stuart.morgan
Status: NEW → ASSIGNED
(Assignee)

Comment 9

10 years ago
Created attachment 305773 [details] [diff] [review]
mixed state

Option 2: Use mixed state, as suggested by mento.

I'm not wild about this version, but if others like it better I'm fine with that.

Discuss amongst yourselves, and we can pick one to land.
Created attachment 305802 [details]
Mixed state on 10.3.9

Mixed state is not terribly visible on 10.3, I don't think.
Created attachment 305803 [details]
Mixed state on 10.5.2

10.5.2, by comparison, is more noticeable, but odd.
(Assignee)

Comment 12

10 years ago
The reason I prefer bold I think is that if a user says "huh, why is my search field blue?", I think the bold draws the eye to the answer much more clearly.

Comment 13

10 years ago
Comment from my partner (10.5/Camino1.6b):
The mixed state is confusing. What does that 'hyphen' mean there ?

We both vote for the bold.
(Assignee)

Comment 14

10 years ago
Comment on attachment 305772 [details] [diff] [review]
bold fix

I'm hearing all votes for bold, so let's go that route.
Attachment #305772 - Flags: superreview?(mikepinkerton)
Comment on attachment 305772 [details] [diff] [review]
bold fix

sr=pink
Attachment #305772 - Flags: superreview?(mikepinkerton) → superreview+
(Assignee)

Comment 16

10 years ago
Landed on trunk and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: fixed1.8.1.13
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.