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.
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
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
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
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
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 :-)
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
*** 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
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
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.
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
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
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
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
*** 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
*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.
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.
* 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
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
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.