626066 - History, Bookmarks menus too wide because of pages with long titles

Status: NEW

(Core :: Widget: Cocoa, defect)

Description

[Florens Verschelde :fvsch]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

This is--in my opinion--a slight usability issue on OSX, possibly on other systems as well. When web pages have a LOOONNNG title, which is pretty common, they appear in the History menu, or when bookmarked in the Bookmarks menu, truncated to a number of characters or words.

The issue is that this number is quite high, which means the History and Bookmarks menu (or submenus) are often very wide, while other menus (File, Edit, Tools, etc.) are reasonnably narrow.

I have documented this issue with screenshots and comments:
http://dl.dropbox.com/u/145744/screens/ff-widemenu_indexed.png

I suggest using a smaller number of characters/words when truncating, and/or allowing users to customize this. See the comments (red text) in the above image for details.

Reproducible: Always

Comment 1

[Florens Verschelde :fvsch]

Attachment: Different screenshots of issue, with comments

Comment 3

[Anthony Ricaud (:rik)]

This doesn't look like a duplicate to me. The other bug is about a larger default width, this one is about an unusually long width.

Comment 4

[Alex Limi (:limi) — Firefox UX Team]

Agreed, we should limit the width of bookmark and history items. I assume there's a threshold kicking in already, but it seems much to wide.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

This is a duplicate of that bug. We had to increase the maximum menu width to accommodate some locales that use long strings. We'll make this properly locale-dependent post Firefox 4.

Comment 6

[Florens Verschelde :fvsch]

In the issue as I report it, bookmarks are clipped at around 130 characters. This is more than twice the design “best practice” of having line lengths around 50-70 characters. It also results in barely usable History and Bookmarks menus as highlighted in the attachment for this bug.

I don't understand how localizing the max width of items would fix this issue.

Comment 7

[Florens Verschelde :fvsch]

Reopening because:
- In bug 625369 the increased width of bookmarks is 70 characters (increased from a previous setting of roughly 50 characters).
- In this bug we're seeing bookmarks that are 140 characters.

Is this a Mac-specific bug? I guess mac menus might be handled differently, with the clipping handled by the system rather than Firefox itself?

Comment 8

[Shawn Wilsher :sdwilsh]

Just because it's a different width does n0t make it a different bug.

Comment 9

[Florens Verschelde :fvsch]

I disagree, on two accounts:
1. bug 625369 is "max width of bookmarks has changed and is slightly too big" (and the answer was "the change is intentional, we may fine-tune in the future") while this bug is "max width of bookmarks is MUCH too big". Twice as big as the already increased value hints at a *different* issue that may not (will not?) be solved by future localization settings.
2. bug 625369 reports an issue on Windows. This is an issue on OS X. I have little knowledge of this, but I reckon Firefox uses different libraries and possibly different internal code for handling menus in different OSs. Can we tell for certain that this is not a OS X specific issue?

Elements that would be helpful for fixing this bug OR solving it as a duplicate with enough information to do so:
- Can other MAC users confirm this issue? (Please use a bookmark title of more than 200 letters. I can give detailed steps to reproduce what's in the attached screenshot if needed.)
- If there is a hard max width for truncating history/bookmark entries, what is this limit exactly (X letters, Y words, Z pixels?)?
- Is that limit consistent with the observations in this bug? In other words, does it explain these observations? If yes, solve this bug as duplicate of bug 625369. If not, investigate as a mac-specific issue (if only seen on mac).

(Reopening. I am persistent but not stubborn, so if my point is deemed invalid I’ll just move on.)

Comment 10

[Anthony Ricaud (:rik)]

Another thing that makes me think it is not the same issue:

In bug 625369, Firefox/4.0b10pre ID:20110112150051 is said to be ok. Florent is seeing this in beta9 so before the problem seen in bug 625369.

And the commit that changed this is http://hg.mozilla.org/mozilla-central/rev/a4cbf4b8928b. So max-width: 32em is not as long as seen in this bug.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

OK, sorry for being hasty. I think this probably is a separate issue if it's Mac only, since the styling touched in the original bug is Windows/Linux only.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Need a regression window to make further progress on this bug, I think.

Comment 14

[Anthony Ricaud (:rik)]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2370ecfdcbb7&tochange=6272ce1da6f5

Running the mozregression tool, I got this range.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

The only possible thing that could have affected this in that range is switching to 32/64 bit universal builds (assuming that's what those changesets actually do), but even that would be rather odd.

Comment 16

[Anthony Ricaud (:rik)]

I just run 20110317 nightly in 32 bits mode and the menu is not wide. So this is definitely a 64bits problem.

Comment 17

[Detlef Kretschmer]

This is NOT a duplicate and applies to 6.0.1 as well. In Windows, the menu item is part of the FF window, not in Mac OS.
In Windows the problem can be fixed using userChrome.css, this does not work in Mac OS

Comment 18

[Detlef Kretschmer]

(In reply to Anthony Ricaud (:rik) from comment #16)
> I just run 20110317 nightly in 32 bits mode and the menu is not wide. So
> this is definitely a 64bits problem.

I doubt this, I am still running on Mac OS 10.5.8 and I have the problem since FF5
Hardware is 2x2.8 GHz Quad-core Xeon

Comment 19

[Detlef Kretschmer]

I just went up to FF7.0b2 - problem persists

Comment 20

[Detlef Kretschmer]

Just to make things interesting: History shows the same silly behaviour.

Comment 21

[Detlef Kretschmer]

Done some updating: I am now on FF7.0b2 and Mac OS 10.6.8
The problem persists in 64 bit and 32 bit. This is definitely not a 64 bit problem.

Comment 22

[Rolf Breuer]

Just the same with FF9.01 and Mac OS X 10.7.2

Comment 23

[Eckard Berberich]

The problem stills persists with FF 11.0 and Mac OS X 10.6.8

Comment 24

[u279076]

Is this still an issue for anyone?

Comment 25

[Anthony Ricaud (:rik)]

Yup, still an issue.

Comment 26

[u279076]

(In reply to Anthony Ricaud (:rik) [out until July 15] from comment #25)
> Yup, still an issue.

Which version did you use? Does it reproduce in the latest Firefox Nightly?

Comment 27

[Eckard Berberich]

Still the same issue in FF 22 and Nightly 25.0a1.
Running Mac OS X 10.6.

Comment 28

[u279076]

Thanks Eckard.

Gavin I'm wondering how we can proceed with this bug? The regression window is quite old so I'm not sure what can be done. Maybe an engineer can look at the menus code to see what might cause this to happen?

Comment 29

[Anthony Ricaud (:rik)]

I think the 64-bit switch that we saw at the time is still the core of the issue. I have no idea why OS X frameworks would behave differently.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

Sounds like a cocoa widget/popup issue of some sort, maybe smichaud has an idea.

Comment 31

[Steven Michaud [:smichaud] (Retired)]

Someone please post a link to a page with a very long title, which can be used to reproduce this bug.  Please also provide detailed STR.

Comment 32

[Anthony Ricaud (:rik)]

STR:
1. Bookmark any page in the top level Bookmarks menu (that's the default when clicking on the bookmark star in URL field)
2. Change the bookmark title to a really long string
3. Open the Bookmark menubar

Actual:
See attachment 504130 [details]

Expected:
This menu's width should be smaller.

Comment 33

[Steven Michaud [:smichaud] (Retired)]

As best I can tell, there's no longer any difference in behavior between 64-bit mode and 32-bit mode.  And it's a relief not to have to deal with that weirdness.

I agree that menu items corresponding to long titles are "too long", but it's very difficult to tell who's at fault.  For example (as others have pointed out) menus work very differently on Windows and Linux -- too differently to tell whether or not the problem lies in cross-platform code.

Very long menu items *are* abbreviated (using "..."), but I don't know where that comes from (from cross-platform code, from Cocoa widget code, or from the OS).  Anyone know?  (I could try to find out myself, but it'll be a while before I have time to do that.)

Comment 34

[Stefan [:stefanh]]

XUL menu/menuitems do have a max-width set in menu.css (line 154-157):

menupopup > menu,
menupopup > menuitem {
  max-width: 42em;
}

I doesn't look like the native menu implementation honor any of this css styling and when it comes to width I don't see any obvious way in the NSMenu and NSMenuItem documentation to set a max-width (or a width for that matter). I suppose the title string could be truncated if it's over a certain length to limit the width of the menuitem (won't really match the css, though).

Comment 35

[bintoro]

Here’s what I believe is going on:

(1)  The width of the menus is not being constrained in any way. They expand to accommodate their contents up to the screen edge or whatever the OS allows.

(2)  The menu items are always created with full-length titles. In other words, no truncation happens at the application level.

This is a diagram of my actual Bookmarks menu with two submenus open: http://i.imgur.com/ChVVFEr.png

The first level menu is 1154px wide because that’s the width of the longest title; no truncation happens here. The second level contains truncated items because the size of the submenu is now limited by the screen edge. The third level also contains one truncated item because the OS won’t expand the submenu past the left border of the first level.

Judging by this behavior, I’d say the truncation is only happening due to OS intervention when the items won’t fit on the screen anymore.

The bug could be fixed by remedying either (1) or (2) above. Either set a maximum size for the menu and let the OS truncate the titles, or set up an unconstrained menu like now but feed it truncated titles.

The origin of this bug is possibly explained in bug 459729.

(In reply to Stefan [:stefanh] from comment #34)
> I doesn't look like the native menu implementation honor any of this css
> styling and when it comes to width I don't see any obvious way in the NSMenu
> and NSMenuItem documentation to set a max-width (or a width for that
> matter).

Perhaps the answer is NSMenuDelegate and its method confinementRectForMenu that allows one to specify screen coordinates within which the menu should appear. It requires absolute coordinates, though, so some calculations would be needed to figure out the correct placement. Also, I don’t know if confinementRectForMenu is enough to invoke the automatic truncating behavior or if OS X would just stretch the menu anyway. The documentation says: “The returned rect may not be honored in all cases, for example, if it would force the menu to be too small.”