XP menus should be scrollable. i.e. charset menu.

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

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

Note that currently (at M9) Window and Unix clients have a problem showing all the charset menu items. But Mac uses an extendable menu and does not have the problem.

How difficult is this? Considered a usability blocker, especially for I18N. reassigning to saari

This is either going to be trivial, or a complete pain in the butt, hyatt will have a better feeling for the difficulty. Let me take this opportunity to say that we as a company abuse menus in every way imaginable. Having 40+ options in a menu for a charset is not good UI. Given that, and the fact that this is XUL and easily made more manageable (hierarchical menus at the very least) this doesn't fall very high on my dogfood priority list.

I concur. This bug should not need to be fixed for dogfood. The charset menu blows, and it should be fixed.

This isn't limited to the charset menu, any menu that can grow (e.g., bookmarks, mail folders, windows, etc.) is susceptible to being chopped off. This is considered by the leads to be a usability blocker for beta, although we will take into consideration a realistic estimate of the time required to implement. Please provide one in the whiteboard summary.

2 days.

yes the charset menu is a terrible ui, but that still isn't an excuse not to make this functional. it's not just a problem with 40+ item menus, it's a problem for anyone who has medium size menu and isn't using a 21" monitor at high resolution. fixing this menu isn't just polish, it really is a fundamental usability isue for alot of our users -- not just people outside the ISO-8859-1 speaking world. i have an m11 task to build an entire new UI for the charset menu, but it doesn't eliminate the need for a complete list of the charsets that a user can use with mozilla. this is worth 2 days of work.

Aye, this needs to be done, I'm just wondering if it needs to be done for dogfood. I most certainly don't want this to be an excuse for bad UI, and that includes the bookmarks menu (which we seem to be forever stuck with). Alas, I talked with hyatt, and he isn't sure we can make this work yet...

tague, even though we will probably do this work for beta, I think you should consider implementing a charset selection UI that doesn't use an exhaustive enumeration of the choices in one or more menus. Don't the vast majority of multi-lingual surfers just switch between a tiny subset of charsets? Even with grouping and multiple submenus, selecting one item from many is a terrible interface, as you say. This also applies to all of the user-extendable menus that will have to scroll, but we shouldn't create any such menus for the user.

The current UI proposal for the charset menu includes "customize..." option for the charset menu by which the user can add menu items. Once this is implemented, the problem should be alleviated.

I meant to say "add or delete" menu items.

That just puts the problem off on the user, who is least equipped to deal with it. My point is that we should never foist a menu on the user that has more than a few items. Even with a way to delete them, the vast majority will never use it and still suffer. If this type of solution is the best we can do, why not just put the 3-4 most common choices in the menu to start? Anyway, this discussion belongs elsewhere.

Peter, without elaborating what's in our current proposal, we are going to implement the charset menu UI in a way that's targeted for average users as you suggest.

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

I found a workaround to display all charset menu items in Windows: 1) Move mouse cursor to the lowest visible item from charset menu. 2) Gradually lower the cursor until it changes into double-headed arrow shape. 3) At this point, left click and lower the Windows Taskbar out of the view. ==> The menu content will move up, displaying the entire charset menu. When charset menu is viewed with previously lowered (hidden) Windows Taskbar, bringing it back up to default position in same manner will also do the trick.

Thanks for this (partial) workaround suggestion. I tried it on my 17 inch monitor and it worked to some extent. What this workaround seems to accomplish is: to position the top of the Charset menu to the top of the Monitor window and then draw the menu from there. Since the top of the Charset menu normally begins at the height where the "View | Character Set" menu is positioned, this re-positioning of the top edge gives you the full screen height to display the menu. Unfortunately on my 17 inch Windows monitor, repositioning still leaves out 13 or 14 menu items.

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

Should long menus be scrollable, or should the menu items of long menus be drawn in multiple columns (as they are for the bookmark popup menu in 4.x)? I would prefer the later for useability reasons. I find it easier to find and choose a menu item if they are available on the screen all at once, than having to scroll up/down the list of items to find what I need.

Since Kat's charset menu UI proposal now specifies a "Customize..." menu item that whisks you off to a separate dialog instead of an unwieldy long menu, I am removing this bug from the I18N blocker list (14744). If anybody continues to think that this scrollable menu bug is a blocker for I18N, contact me.

Chris, I was about to lower the priority of this bug to p2 or p3, but since you were the one to bump it from p3 to p1, I'll leave it to you to adjust.

Lowering to p2. Dependent upon Eric's gfx scrolling stuff

Putting on [PDT-] radar...not a blocker for true dogfood....or beta yes :-)

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

Bad news...saw this with my own eyes...changing to PDT+.

deleting PDT+, please re-evaluate whether this is really required for dogfood. It now affects few users, there are workarounds, and all other concerned parties agree that this is no longer a blocker, therefor lower priority.

Should you delete [PDT-] or should you bring it to the PDT team attention?

Added dependency to bug# 9454, since the XP menus should at least be positioned correctly on-screen in the vertical direction before you go about making them scroll.

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

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

removing dependency on 9454, this bug does not depend on that fix. Michael, please don't add dependencies just because you think bugs should be fixed in a a particular order. Instead, vote for the bugs you want fixed most.

trudelle: well if you think about it for a moment, it is pretty silly fixing this bug if bug #9454 isn't yet fixed - if the user can only see a little bit of a menu on the screen they won't care if they can scroll it or not. Bug #9454 is also probably much easier to fix. Leaving for you to decide in your infinite wisdom.

Michael: you cite quite good reasons for prioritizing this lower,but there is still no dependency. I'm trying to avoid unnecessary dependencies, because they generate a storm of notifications when a bug is changed. I have left it up to saari how to prioritize this, and I'm sure whatever he does will make sense. Thanks for your endless patience.

We think it's a PDT+, Peter, please email PDT if you don't agree rather than changing the status.

mass-moving most m11 bugs to m12

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

I've gotten a lot of input from folks that have reviewed the current PDT+ list that this item stands out as very "non +" class at this point. To champion that fact, I'm going to remove the plus, and get it reconsidered yet again at the PDT meeting tomorrow. If folks on this list have comments, please chime in. I've heard that the international concern his been reduced with the restructuring of the character set menus. The only remaining concern (that I can think of) appears with gigantic bookmarks lists... and those can either be avoided, or the sidebar can be used to access them. Thanks, Jim

My team has been saying for 6 weeks that this is not a dogfood stopper, and should not be PDT+. Nothing has changed since then, so we still feel that way.

Putting on PDT- radar.

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

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

taking popup/menu bugs. I hate my life.

Any chance of getting this for beta?

BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.

bulk accepting xpmenu/popup bugs. sigh.

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

Putting dogfood in the keyword field.

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

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

It *may* save time to fix bug 21154 at the same time as fixing this bug. [Dogfood is in keywords, so removing from summary.]

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

We'll catch 75% of users by just overflowing with a scrollbar. There won't be autoscrolling, that will be covered by a different bug. My suggestion is to use a treeView for bookmarks for anything that is a hierarchical that we know will probably scroll to avoid a truly crappy user experience.

Yeah, i agree. it would be nice to do our popup tree from MozillaClassic for the folder buttons on the personal toolbar.

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

Mass-moving most M15 bugs to M16

So, what's the final resolution on this one? Will we have scrollable menus or not? We need an answer in order to decide if we are going to keep the cascaded submenus. Thanks!

reassign to evaughan for wrapup on Windows. needs update on remaining duration and target landing date.

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

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

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

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

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

I know it says dogfood but I'm nominating for nsbeta2 as well.

reassigning to saari, need fix for dependency, and updated landing date estimate.

Putting on [nsbeta2+] radar for beta2 fix.

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

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

For beta 2 we will have a scrollable menus via a scrollbar. This will, in theory, work when Eric checks in his changes. He is currently resolving issues with that code. However, this is unlikely to be the final solution as we probably want a more Mac or Windows-esq scrolling of menus via up or down arrows on the top or bottom of the menu, drag scrolling etc. After talking with Pinkerton, a quick swag for this is 3-4 days, although I definitely need more input from hyatt.

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

To do anything more fancy than the scrollbar in a menu will probably require a week and a half. Maybe just a week if it is evaughan doing the work as he is more familiar with the view code. This is based on a swag from hyatt.

This bug propably caused bug 39019.

I think we have to provide for eliminating the scrollbars, and using auto-scroll instead, with arrows to indicate there is more content that can be scrolled into view. We need more than a swag for this, I'm waiting for a task breakdown and reliable estimates of the tasks involved, in days, not weeks.

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

assigning to evaughan for task breakdown and estimate, and to determine possible overlap with Bug 32730. Need to offload as much of the implementation as possible to someone else.

removing nsbeta2+ for reconsideration now that we have menus scrolling. We are proposing to do auto-scroll and scrolling without scrollbars post-beta2. moving to m18

*SPAM* - adding mostfreq keyword to bugs with loads of DUPEs. Please aid this effort by adding this keyword to any bugs with more than 15 DUPEs. Gerv

Putting on [nsbeta2-] radar.

Putting on nsbeta3 keyword. Promised trudelle he could still do for product.

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.

Evaughan's task breakdown: 1 day to build a nsScrollBoxFrame. 0.5 days to build stand alone auto repeating buttons. 2 days to integrate and hook it into the current system.

Michael Lowe asked, if we will have multi-column menus, but there was no answer. 4.x Unix (is it Motif?) create a "More..." menuitem as last item, which will create a new column with the next items right to the current one. I am very used to this and consider the 4.x Windows behaviour (scrolling) a pain. Note, that this bug is also important for dropdown boxes in web content, often used for the country in reigstration forms.

Column menus: * have nowhere to go once you get to the side of the screen (see also bug 33188) * break the visual relationship, if it exists, between the item at the end of one column and the item at the beginning of the next * make it impractical to arrange a large popup menu (e.g. the font menu in prefs) to pop up with the current item under the mouse (you'd need two `More...' items, one at the top and one at the bottom!) * cause lots of misfires if you mouse over a submenu in the first column on the way to a normal menu item in the second column * are no longer (Windows 2000) used by MS in the Start menu, as scrolling menus are used instead (presumably because columnar menus were found to be too hard to use).

Matthew, you don't like them. That's fine. I depend on them. * They are faster (one click opens one page of menu items) * They give a better overview (as pointed out my Michael; I see half a screen full of menu items) > * have nowhere to go once you get to the side of the screen (see also bug 33188) There are lots of suggestions in the bug. E.g. simply go the left. > * cause lots of misfires if you mouse over a submenu in the first column on > the way to a normal menu item in the second column Huh? It's no different from targetting the last normal item in the first column.

i hope not. I find the 'more' option a pain in the ass. Using list boxes on windows is SO much nicer being able to grab a scrollbar and just scroll down.

Putting on [dogfood-] radar since [nsbeta2+] already indicated.

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

fixed. XP menus now have autoscrollers.

Bookmarks scroll waaay too slowly for large bookmark lists. Currently, it can take > 30 seconds to scroll through my bookmark list. The currently solution to this bug isn't working. Please return scrollbars ASAP.

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

This feature is implemented, if you have a problem with the implementation, report it as a defect in another bug report, do not reopen the bug report used to track the feature implementation. If you want a different implementation, file another bug as an enhancement request to the product. resolving as fixed.

verified fixed