Closed Bug 11586 Opened 21 years ago Closed 20 years ago

[FEATURE] XP & content menus need to be scrollable

Categories

(Core :: XUL, defect, P1)

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: pavlov, Assigned: eric)

References

Details

(Keywords: polish, Whiteboard: [nsbeta2-][dogfood-]3.5 days)

XP menus should be scrollable.  i.e. charset menu.
*** Bug 9276 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M11
*** 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.
Assignee: hyatt → saari
Status: ASSIGNED → NEW
Summary: XP menus need to be scrollable → Dogfood: XP menus need to be scrollable
How difficult is this?  Considered a usability blocker, especially for I18N.
reassigning to saari
Status: NEW → ASSIGNED
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.
Blocks: 12667
Blocks: 12670
*** Bug 14584 has been marked as a duplicate of this bug. ***
Blocks: 14744
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.
Blocks: 15157
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. ***
Priority: P3 → P1
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.
No longer blocks: 14744
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.
Priority: P1 → P2
Lowering to p2. Dependent upon Eric's gfx scrolling stuff
Whiteboard: [PDT-]
Putting on [PDT-] radar...not a blocker for true dogfood....or beta yes :-)
*** Bug 9276 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT-] → [PDT+]
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.
Whiteboard: [PDT+]
Should you delete [PDT-] or should you bring it to the PDT team attention?
Depends on: 9454
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. ***
Summary: Dogfood: XP menus need to be scrollable → Dogfood: XP & content menus need to be scrollable
*** Bug 16765 has been marked as a duplicate of this bug. ***
No longer blocks: 16765
No longer depends on: 9454
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.
Whiteboard: [PDT+]
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
Whiteboard: [PDT+] → [PDT+] 12/3
*** Bug 18519 has been marked as a duplicate of this bug. ***
Target Milestone: M12 → M13
Whiteboard: [PDT+] 12/3 → [P-D-T??] 12/3
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.
Whiteboard: [P-D-T??] 12/3 → [PDT-] 12/3
Putting on PDT- radar.
QA Contact: phillip → sairuh
Component: XP Toolkit/Widgets → XPMenus
Whiteboard: [PDT-] 12/3 → [PDT-]
*** Bug 21016 has been marked as a duplicate of this bug. ***
Priority: P2 → P1
Summary: Dogfood: XP & content menus need to be scrollable → [FEATURE] Dogfood: XP & content menus need to be scrollable
Target Milestone: M13 → M15
*** Bug 21725 has been marked as a duplicate of this bug. ***
Assignee: saari → pinkerton
Status: ASSIGNED → NEW
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.
Component: XPMenus → XP Toolkit/Widgets: Menus
bulk accepting xpmenu/popup bugs. sigh.
Status: NEW → ASSIGNED
*** Bug 26080 has been marked as a duplicate of this bug. ***
Putting dogfood in the keyword field.
Keywords: dogfood
*** Bug 26804 has been marked as a duplicate of this bug. ***
*** Bug 22276 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT-] → [PDT-] 3 days?
It *may* save time to fix bug 21154 at the same time as fixing this bug.



[Dogfood is in keywords, so removing from summary.]

Summary: [FEATURE] Dogfood: XP & content menus need to be scrollable → [FEATURE] XP & content menus need to be scrollable
*** 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.
Whiteboard: [PDT-] 3 days? → [PDT-] 2 days
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. ***
Blocks: 20761
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
Whiteboard: [PDT-] 2 days → [PDT-] 2 days TFD 4/14
Whiteboard: [PDT-] 2 days TFD 4/14 → [PDT-] 2 days TFD 4/21
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!
Whiteboard: [PDT-] 2 days TFD 4/21 → [PDT-] 2 days TFD 4/28
reassign to evaughan for wrapup on Windows.  needs update on remaining duration 
and target landing date.
Assignee: pinkerton → evaughan
Status: ASSIGNED → NEW
*** 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.
Keywords: nsbeta2
reassigning to saari, need fix for dependency, and updated landing date 
estimate.
Assignee: evaughan → saari
Whiteboard: [PDT-] 2 days TFD 4/28 → 2 days TFD ??/??
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: 2 days TFD ??/?? → [nsbeta2+]2 days TFD ??/??
*** 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.
Whiteboard: [nsbeta2+]2 days TFD ??/?? → [nsbeta2+] 1.5 weeks for something better
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.
Assignee: saari → evaughan
Whiteboard: [nsbeta2+] 1.5 weeks for something better → [nsbeta2+] 1.5 weeks (Need task breakdown)
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
Whiteboard: [nsbeta2+] 1.5 weeks (Need task breakdown) → 1.5 weeks (Need task breakdown)
Target Milestone: M16 → 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
Keywords: mostfreq
Putting on [nsbeta2-] radar. 
Whiteboard: 1.5 weeks (Need task breakdown) → [nsbeta2-]1.5 weeks (Need task breakdown)
Putting on nsbeta3 keyword.  Promised trudelle he could still do for product.
Keywords: nsbeta3, polish
Target Milestone: M18 → M20
*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.
QA Contact: sairuh → jrgm
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.
Whiteboard: [nsbeta2-]1.5 weeks (Need task breakdown) → [nsbeta2-] 3.5 days
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.
Whiteboard: [nsbeta2-] 3.5 days → [nsbeta2-][dogfood-]3.5 days
*** Bug 43302 has been marked as a duplicate of this bug. ***
fixed. XP menus now have autoscrollers.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** 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.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
verified fixed
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.