45700 - scrolling menus aren't ideal for large bookmarks lists

Status: NEW

(Toolkit :: UI Widgets, enhancement)

Description

[Brad Barnett]

Bookmarks have been partially fixed, but are still inadequate when it comes to
large bookmark lists.  My bookmark list is about 6 or 7 panes in netscape
currently, but it takes about 30 seconds to scroll through it with mozilla.

The problem _was_ fixed, when bookmarks had a scrollable bar ... allowing you to
_quickly_ scroll through them.  Even better, you could use your wheel on a wheel
mouse to zip through them with ease.

I really feel that the current state of the bookmark list is almost as useless
as _not_ having a scrollable list at all!  30 seconds is way, way too long to
wait to scroll through the list, and having to move all the way to the bottom of
the list, or top to do so is unacceptable.

Please fix this horror.  Please.

Comment 1

[Claudius Gayle]

ranting bug reports are hard to decipher...

so is your bug that a long BM list doesn't scroll fast enough for you and you'd like it to be faster or what?
without a clear statement of the problem and expected results, it is very difficult for any action to be taken with this bug
please see/use:
http://www.mozilla.org/quality/bug-writing-guidelines.html

http://www.mozilla.org/quality/help/bug-form.html

Comment 2

[Brad Barnett]

reopened 11586, and closing this bug

*** This bug has been marked as a duplicate of 11586 ***

Comment 3

[Brad Barnett]

OK, as reopping 11586 isn't allowed, I'll come back to this bug and re-open it.

It really isn't that difficult to see what the bug report is.  If you're having
problems understanding my initial post, your reading comprehension needs to
improve.

Thanks.

Comment 4

[Claudius Gayle]

Mr. Barnett, my reading comprehension is fine, thanks for your concern. I would suggest you refrain from such personal
comments in the bug database in the future.

I was simply prodding you for more information because I hoped to champion your cause. If you read the page I
recommended you would know that a clear, succinct, and complete 'just the facts' style bug report is likely to be
'confirmed' quickly and thereby head much more quickly down the road to being fixed.

Comment 5

[Brad Barnett]

Well just what am I supposed to do then? Not rant?  

Whomever "fixed" bug #11586 did NOT do an acceptable job.  I spent hours
rechecking that bug for resolution, and entering polite suggestions.  The result
was a fix which wasn't even checked by the people that implemented it, to see
how usable it was.  In fact, if you'll please read bug 11586, you'll see that
the fix taken completely ignores those that reporting the bug! 

Bug #11586 needs to be reopened, because there isn't a fix for it, and it hasn't
been resolved.

Comment 6

[Claudius Gayle]

[FEATURE] bugs are special cases, once the feature is implemented the bug is marked verified/fixed. Bugs with the feature are 
written up separately.
This bug is being resolved as invalid and should not be reopened unless/until complete information is provided in the proper 
format. That format cabe found at:
http://www.mozilla.org/quality/bug-writing-guidelines.html

Comment 7

[Brad Barnett]

This is a valid bug, and I'm not going to take my time (on principal) reading
some lame html document.  You're getting paid for this, I'm not.  Do your job. 
Its quite clear what the bug is about.

I won't bother with this any more, you can reclose it if you want, and I won't
bother reopening it.  Just chalk this up to another concerned user that got
brushed off, too many times.

Your actions alone aren't responsible for this.  Much of what happened with bug
11586 is.  People don't have time to help YOUR ORGANIZATION and jump through
your little hoops, to help YOU.

Yes.  Help you.

Comment 8

[Brad Barnett]

Please reassign this bug to someone willing to work on it.

Comment 9

[Chris McAfee]

m19

Comment 10

[Greg Miller]

The original reporter said things in an inappropriate way, but he's right.
Bookmarks are in a very sad state in Mozilla, due to a combination of factors:

(1) Autoscrolling menus vs. multicolumn menus. These seem to be theoretically
appealing to people who don't have to use them constantly, but they're a large
pain for those of us who do. The multicolumn menus in 4.x were fast and
extremely usable. Scrolling should be a backup and not a first attempt to deal
with large bookmark lists. Unfortunately, any request for multicolumn menus gets
an automatic WONTFIX. The old scrollbar-based approach wasn't too bad, and I'd
be satisfied with that if multicolumn menus offend the sensibilities of UI
designers too much.

(2) Bug 50346. The bookmarks menu gets chopped off at the bottom after you've
been using it for a while.

(3) Bug 41888. The 4.x "File bookmark" option is not implemented, making it
difficult to put the bookmark where you want it.

(4) "Manage bookmarks" crashes sometimes lately when dragging a bookmark to a
new location as soon as it starts to autoscroll (trunk build).

None of these is serious enough to convince anyone they're rtm++, so they don't
get fixed. What doesn't seem to be considered is that the combination makes the
current nightlies look like a Beta 1 candidate to people who use the bookmarks
system extensively. Fixing any two or three of them would probably be good enough.

Comment 11

[Claudius Gayle]

Issue (4) is bug 55646 and fortunately occurs only on trunk builds so no need for the rtm
merry-go-round.

Clearly, for issue number (1) people are in disagreement with you. I for one believe scrollbars
on a menu are clunky and look horrible. The scrollbars themselves aren't what's necessary
here, you really just want the menu to scroll faster. Nonetheless, that's a UI design question
that I'm sure has already been aswered by a designer but probably belongs discussed on the n.p.m ui
newsgroup.

I was just bitten by issue (2) bug 50346. Unfortunately, it lacks a reproducible testcase. This makes
it extremely difficult to fix, and impossible to get checkin approval because we cannot assess the full
extent of the problem (how many peole see this, how often, etc.).

So in the end (1) won't be 'fixed', (4) doesn't apply, we don't have enough info on (3), and last I
heard a mozilla contributor was working up a patch for (2) but I doubt it's likely to make the
branch at this late date :-(. Sorry I don't have the good answers for you.

Comment 12

[Blake Ross]

Reassigning 79 Bookmarks bugs to Ben.  I was told this was going to be done 
shortly about two months ago, but it clearly hasn't been.  I think that's long 
enough for all these bugs to remain assigned to nobody.

Feel free to filter all this spam into the trashcan by looking for this string 
in the message body: ducksgoquack

Comment 13

[Keyser Sose]

This occurs in Windows too..This is the last bug thats keeping from not using
Mozilla exclusively. Frankly its really annoying.

Comment 14

[Keyser Sose]

This is a duplicate of my bug report. Frankly this is a poorly written bug
report as well. Marking as such.

*** This bug has been marked as a duplicate of 62907 ***

Comment 15

[Marcia Knous [:marcia]]

Netscape Nav triage team: this is a Netscape beta stopper.  Important for daily 
use.

Comment 16

[Brad Barnett]

This bug isn't closed and it certainly is _not_ a duplicate of 62709.

For over 12 months, people have been trying to bash this concept into *anyone's*
head over there.  Bookmarks are unusable as they are, with large lists.

Fix this please.

No, having them scroll faster won't work.  When you have 300 bookmarks,
scrolling with little arrows at the top and bottom of a 1600x1200 screen isn't
workable.  You have to move all the way to the bottom of the screen, and then
click.  And then wait.  Speeding up this process only means that you will surely
fly past the bookmark you want, and you will have to move to the top of the
screen to scroll back.

This is very annoying.  Everyone with large bookmarks agrees its annoying. 
Someone over there just don't want to fix this.  There have been at least 3 or 4
seperate bugs reported specifically outlining the problem, but there is always
resistance.  Always bugs closed.  Always duped to something that's not quite the
same.  Initially, I was very polite about this.  I walked through the hoops.  I
tried to help.  At this point, its apparent no one cares except for people with
large bookmarks.

Its quite clear that no one there has a large bookmark list.  That's ok.  No one
is faulting you or your organization for that.  Your fault sits in your
inability to take the word of people who have to deal with this problem on a day
to day basis.  You seem to think that "If its not a problem for me, its not a
problem for anyone".

Have you tested Mozilla with large bookmark lists, placing some of your favorite
links in deep (200 or so), and then used that for 2 months?  If not, how can you
possibly claim that this is usable, or that its unimportant.

Comment 17

[timeless]

reporter: please contact ksosez or asa on irc.mozilla.org and ask for help in 
writing a clear description of your problem.

ksosez's bug is clear, rantfree and received attention from a developer.  This 
bug is useless and contains a lot of rants which do not help developers.

*** This bug has been marked as a duplicate of 62907 ***

Comment 18

[Claudius Gayle]

"For over 12 months, people have been trying to bash this concept into *anyone's*
head over there.  Bookmarks are unusable as they are, with large lists."

Maybe if you'd stop with the bashing it might be easier to see what you're getting at.

I'm going to undupe this bug because I don't believe they speak to the same issue.

Since the problem has never been clearly stated I'm left to my own interpretations.
I believe the reporter's contention is that the current implementation of scrolling menus
scores very low useability-wise. If for example one had 250 bookmarks and wanted to select
the 107th from the bookmarks menu, it would be quite a challenge to land on that exact one.

I've seen two solutions, or implementation suggestions so far:
The first was to use a scrollbar on the menu itself. I know that this was once implemented
as a temporary hack. IMO, i think it was a horrible cross-bred contraption and should never
return.
The second was to use multicolumn menus instead. I think there are plusses and minuses
here. What happens after you've got more than 4 columns? What'd 4.x do? I think this is
great for bookmarks up to 150 or so but what do you do when you're trying to find the 503rd
bookmark?

Lastly what if we were to combine the two? At the bottom of the bookmarks menu you could
the sideways arrow to flyout another column and then just below it the down point arrow to scroll
the current column.

Regardless, this is a design issue and I will forward it over to the proper authorities

Comment 19

[Claudius Gayle]

reassigning to component owner and changing summary.

Comment 20

[hangas]

Triage Team marking nsbeta1-

Comment 21

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 22

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 23

[Brad Barnett]

This bug was to be addressed in 0.7, 0.8, and 0.9 over the months, but its still
not fixed!

PLEASE, PLEASE FIX THIS BUG.

Comment 24

[Matthew T (active 1999-2002)]

No, this report was not `to be addressed in 0.7, 0.8, and 0.9 over the months'. 
Nobody who it was assigned to ever said such a thing. I apologize for not 
getting to this earlier, but I do have a few hundred other bugs to deal with 
too.

The summary of this bug report is correct. Scrolling menus aren't ideal for 
large bookmarks lists. In fact, to paraphrase Sir Winston Churchill (almost 
beyond recognition), `scrolling menus are the worst possible method of quickly 
accessing large bookmarks lists ... except for all the other methods which have 
been proposed from time to time'.

It was once seriously proposed that the Bookmarks menu should be done away with 
entirely. This idea was campaigned against by myself and others, and the menu 
was retained -- not because a menu was the ideal UI for bookmarks, but because 
it was the most convenient. A menu will never be an ideal UI for dealing with 
an arbitrary number of /n/ items, because no matter how you arrange the menu 
there will be some value of /n/ large enough to make that arrangement unusable. 
And now that we have a `File Bookmark ...' menu item in which you can specify 
the folder for a new bookmark, not to mention a fully functional Bookmarks 
window *and* a Bookmarks sidebar panel, you no longer have any excuse for not 
keeping your bookmarks at an appropriate balance of breadth and depth.

The two suggested solutions described in this bug are both objectionable. 
Adding a scrollbar to the menu would, as Claudius rightly says, be a horrible 
cross-bred contraption which wouldn't match platform standards on any OS. As 
for allowing menus to have multiple columns, that would suffer from all the 
problems described I described in bug 11586 -- it would cause confusing overlap 
of a menu with its own submenus, it would suggest a discontinuity between 
adjacent items where no such discontinuity existed, and it would have nowhere 
to go once you got to the edge of the screen, without overlapping existing 
menus and making it almost impossible to backtrack. And unless you had a very 
large screen, multi-column menus wouldn't help with a menu 300 items long 
anyway.

Are auto-scrolling menus a pain if you have 300 items at the root level of your 
Bookmarks menu? Yes they are. If you are going to use the Bookmarks menu as 
your primary access to bookmarks, should you have 300 items at the root level 
in the first place? No you shouldn't. Are we going to allow menus to have 
multiple columns or a scrollbar in order to compensate for your poor bookmark 
organization, in exchange for making every other long XP Toolkit menu worse? No 
we most certainly are not. WONTFIX.

Some responses in advance to the flameage which is probably going to result 
from this resolution:
*   The Mozilla Project is not `over there', unless you're not on Earth. It has
    contributors worldwide.
*   Hold the saliva, I have enough of my own thanks.
*   I do so have a large collection of bookmarks. 269 of them, in fact. I use
    27 folders to allow me to access these bookmarks from the Bookmarks menu
    without problems. If I used a higher resolution display, I'd use fewer
    folders. And if I used a lower resolution display, I'd use more folders.
    It's not hard.
*   No, I'm not getting paid to do this job.
*   The Mozilla Organization consists of a grand total of 12 people, none of
    whom are involved in this bug.
*   You're right, I don't care. No, really, I don't.

Comment 25

[Brad Barnett]

I do appreciate your frankness and honesty.  Most others (in my opinion) have
not correctly addressed this bug, simply because they dance around the issues
involved, or haven't been speaking frankly about it.  However, I do have a few
counter points to make :


1) the assignment I was referring to for 0.7, 0.8, etc, was indeed done.  It was
assigned through the bug tracking system (ie macfee's assignment to M19).

2) auto scrolling menus are a pain if you have more than one column of
bookmarks.  This is not difficult to achieve with an 800x600 screen, mind you! 
They seem to move too slowly, and the biggest of issues is the fact that to
scroll up, you have to move to the entire top of the screen, whereas to scroll
down, you have to move to the very bottom of the screen.

3) the way netscape currently handles multiple columns of bookmarks is
preferable to the way mozilla does.  Whatever problems multi-column bookmarks
have, it is preferable to scrolling bookmarks (without scrollbars)


There is a possible solution, although I don't know if you're implement it. 
Bind some keys to the menu, so you can use them to scroll through them. 
Additionally, bind the mouse wheel to the menu as well, so that you can use the
wheel to scroll through it quickly.  People who do a lot of browsing tend to
have a scroll mouse, so this might fix the problem.

Alternatively, having up and down buttons at the bottom _and_ top of the
scrollbar would allow one to move the menu up and down until you found the a
position that is desirable.  Accelerating the scroll speed with time would also
be helpful.

Considering that you were someone that actually campained to save the bookmark
menu, it makes sense that you want them to be usable.  One doesn't take time and
effort to save something only to see it die.

Comment 26

[Matthew T (active 1999-2002)]

The Bookmarks menu is not going to `die', and any such suggestion is 
disingenuous.

If the mousewheel is not working with scrolling menus, you should file that as 
a separate bug. This bug, however, is to do with giving the Bookmarks menu a 
scrollbar and/or giving it multiple columns, and neither of those techniques 
are acceptable for the reasons I described. Merely repeating your arguments 
won't make them any more valid. WONTFIX.

Comment 27

[Brad Barnett]

No, this bug report belongs here.  Its about "scrolling menus aren't ideal for
large bookmarks lists".  They aren't for medium sized ones either.  Keep in mind
that for every bug report you've had on this (there have been about 2 or 3),
there have been countless others that have seen it in place, and not reported,
and others that don't even have any idea how to report it. 

Surely you can implement mouse wheel and keyboard bindings without adding your
dreaded and feared scrollbars.  This would fix many of the complaints and
problems with this bug.  If the bookmarks menu is open, the up and down arrow
and the mouse wheel can be bound to them while the mozilla window is active.

Comment 28

[Zach Lipton [:zach]]

I think you misunderstood mpt's post. The menu that you feel is not ideal 
(and I do agree with you) is not going to exist any-more and users will 
access bookmarks another way. In affect, the bug is getting fixed, just in a 
different way.

Zach

Comment 29

[Brad Barnett]

MPT certainly didn't seem to indicate that at any point in his post.  In fact,
he specified that he fought to keep menu based bookmarks in mozilla. 
Furthermore, he claimed that the current state of affairs was the best for a
bookmark based menu, since there was no other solution.

Now, if you are claiming there will be another resolution to this problem, then
I urge you to close this bug report with that resolution.  Until this happens,
this bug isn't fixed, and remains open.

Comment 30

[timeless]

zach: <mpt> The Bookmarks menu is not going to `die'.
<mpt> any such suggestion is disingenuous.

Zach: I am requestion that you, as qa of UID, open a thread in news.mozilla.org 
requesting discussion of how wheel mouse scrolling should work in menus.  When 
that's concluded, please file a bug for it.

Comment 31

[Zach Lipton [:zach]]

um, thank you timeless. /me learns not to post in bugs when about to fall 
over or before 10:00 am. I'll start the thread in n.p.m.ui when I am not 
about to fall over as I am now.

Zach

Comment 32

[Joel Turner]

I entered the following on Mozillazine and it really belongs here as well:

In another post, i said rather off the cuff, the i would rather have scrolling
than multiple column menus. I said that because i believed this to be a more
elegant solution.

I have since gone into Both NAV4 and Moz0.9.1 and built multi-hundred bookmark
folders. The NAV4 behavior in such situations is DEFINITELY better.

Some readers have ASSUMED that Brad Barnett is lazy and just doesn't want to
organize his bookmarks. But even if you do organize your bookmarks, i can see
the need for having a subfolder with multi-hundred objects in it. For instance,
a system admin who keeps a list of all in-house web servers(including individual
users) in a folder for easy access. In a large organization like mine, that list
can be very very long.

Matthew Thomas says in bug 45700 that what happens when you reach the edge of
the screen. Well Matt, you obviously didn't take the time to test this, did you?
If you had, you would have seen that in NAV4, when it reaches the right side of
the screen, the last item to appear is "More Bookmarks...". When you click on
"More Bookmarks...", it opens up the Manage Bookmarks window and takes you to
that directory so that you can access any that didn't show up in the cascade.

This works well! It works well enough that if a seperate XP component has to be
built to do this for bookmarks as opposed to other lists, then so be it.

BUT, ranting does not help!!!!! Informed polite discussion will always work
better. Bug 45700 would be a much better bug if it had been worded something
like this:

Please make large bookmark lists work like they do in Netscape Navigator 4.

And then go on to detail why this is important to this particular user. This
should also include detailed instructions to reproduce as per the bug reporting
spec.

Comment 33

[David Hallowell]

Some people prefer 4.x style bookmark menus and others prefer the win98 style of
menu, this is 4xp and also really needs to be a (hidden?) pref, Win2k has
options for whether the Start Menu scrolls (98 style) or cascades (95 style) as
well as hiding rarely used items by default (I *hate* this but it can be turned
off).

If it's a hidden pref then individual Mozilla distributors can easily use what
they prefer and people in the know can also modify it. (I think Ben Bucksch
prefers the cascading menu style but don't quote me on that - but if he does
then that's at least one Mozilla distributor).

Personally I think the pref should be visible (under Appearance?) but hidden
would be fine by me.

Comment 34

[Ben Bucksch (:BenB)]

Yes, being one who sometimes just hits Add Bookmark many times, I am one of
those with 200-item bookmark folders. Yes, I am very much in favor of the old
4.x Unix style, because it allows me to access the menu items multitudes faster,
mo matter how fast the autoscrolling is. I am so much in favor of the 4.x style
that I consider Mozilla broken and I posted my opinion months ago on .ui.


> And now that we have a `File Bookmark ...' menu item in which you can specify 
> the folder for a new bookmark

Yes, it does help, but not in all cases (see below).

> not to mention a fully functional Bookmarks 
> window *and* a Bookmarks sidebar panel

I find both of them unsuitable. They cost too much 'screen estate'.

> you no longer have any excuse for not 
> keeping your bookmarks at an appropriate balance of breadth and depth.

Do not tell me that I shouldn't be too lazy to sort my bookmarks. Sometimes, I
don't have the nerve to sort a bookmark into one of the hundreds of bookmark
folders I have. Later, I don't have the nerve to sort 100 bookmarks of low, but
existant importance.

Anyways, 'I am the user and what I do is always right', or so I heard UI people
say. Be assured that I am not the only user with that habit.

> it would cause confusing overlap  of a menu with its own submenus
[...]
> it would have nowhere
> to go once you got to the edge of the screen, without overlapping existing
> menus and making it almost impossible to backtrack.

Just open a slightly smaller menu on the left, on top of another. E.g.
     |
      |
       |
      |
     |
    |
   |
  screen hor. ->
|
V time

Bug 33188 (which you, mpt, filed!) is basically about that, dating from a time
when we did have 4.x-style menus in Mozilla.

> it would suggest a discontinuity between
> adjacent items where no such discontinuity existed

Normal app menus shouldn't be so long that they don't fit on the screen.
In user menus (bookmarks, open windows), there usually is no correspondance
between adjacent items. Even if there is, it is not too hard to see the
relation, just as it isn't too hard to see a relation between 2 words of one
sentence, that happen to be on different pages of a book.

> And unless you had a very
> large screen, multi-column menus wouldn't help with a menu 300 items long
> anyway.

Maybe not completely, but the current solution is much worse in *both* cases
(small and large screen) with long bookmarks.


My personal preference doesn't have to line up with what is the default in
Beonex Communicator, but in this case, it might, because I consider the current
solution inferiour.

Comment 35

[timeless]

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

Comment 36

[Ben Goodger (use ben at mozilla dot org for email)]

Since we won't be doing this by default, I'm going to close this as WONTFIX. If
anyone feels like implementing this as an aftermarket add-on, reassign to
yourself or [e-mail]. 

Comment 37

[David Hallowell]

lets make this a nobody/helpwanted bug, it's a valid request and if made a pref
won't affect the current behaviour so there's no reason to resolve this bug.

Comment 38

[David Hallowell]

Spam: sorry takes two passes, one to reopen bug, second to reassign

Comment 39

[Teal Bauer [:teal]]

I have a suggestion: Make sideways scrolling arrows.

This is effectively a combination of multi-page menus and scrolling menus, and
it would still allow people to scroll "to page three" by clicking three times.

Comment 40

[Steven Adeff]

Uhmmm... I have a lot of bookmarks too, but I don't have a problem with how 
netscape handles bookmarks because I...
USE FOLDERS IN MY BOOKMARKS

sorry for screaming, but this just seems like it makes too much sense to me and 
people are bitching and moaning too much.

Comment 41

[David Hallowell]

Well until the File Bookmark menu option was introduced then it was a hassle
organising bookmarks into folders into moz, somepeople would still consider it a
hassle as you can't drag and drop into individual bookmark folders at the moment.

Anyway, however a user chooses to file bookmarks is their own choice and this is
a reasonable request for enhancement.

Comment 42

[Jesse Ruderman]

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

Comment 43

[Chris Lyon]

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

Comment 44

[Jesse Ruderman]

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

Comment 45

[Blake Ross]

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

Comment 46

[Illtud Daniel]

Can I pipe up in support of post #32 (do it like NS 4.x did) - and can we
please have an end to posts like #40 ("I don't have a problem with how 
netscape handles bookmarks because I... USE FOLDERS IN MY BOOKMARKS") from
people who don't use their browser in anger (guess what, Mr #40, I do
use folders, and subfolders - over 80 of them to hold my 1,400+ bookmarks).

Anyway, this wasn't supposed to be a rant - just my 2p's worth on something
I consider to be a showstopper in terms of usability.

Comment 47

[[e-mail]]

Perhaps a pref for the number of lines that the arrows should scroll by?

Comment 48

[Ben Bucksch (:BenB)]

Doesn't help at all.
- There is no single appropriate value. If I want to scroll from the top to
bottom, I'd want fast scrolling. If I want to get to a bookmark somewhere at the
middle, I'd need slow scrolling (towards to target) to get exactly where I need to.
- This doesn't solve the "no overview" problem. If I have a menu with 200
entries, I have to read through the *whole* list to find my bookmark, unless I
know that the bookmark is at the very top or bottom (of them *all*). With
"pages" of menus, I can remember where roughly the bookmark was: top or bottom
of the page and 3th or 4th page (photographic memory).

Comment 49

[Brad Barnett]

Ok, guys, this issue is really, really out of hand now.  This bug (including its
parent, 11586) has been around for OVER 2 1/2 YEARS.  I understand that some
things take time, but this bug has literally been unaddressed for that entire
time.  There have been posts stating that it isn't a big deal, or possible
bubble gum patches as solutions, but nothing concrete.

This is a _major_ show stopper if you have more than about 60 or 70 bookmarks on
your main bookmark list.  Secondly, loading time seems to have gotten worse! 
When I start up mozilla under Linux, and click on "bookmarks", there is
_literally_ a 2 1/2 second delay (with 100% cpu usage!) before the pane appears.

There is something very, very wrong with the bookmark code.  I have 910
bookmarks, many organised into one level deep sub categories.  It doesn't matter
_why_ I have 906 bookmarks.  Approximately 400 of them are on the main tree. 
Whether I am a computer dealer with all of my distributors and products that I
carry bookmarked, or someone that has a lot of friends to bookmark, this
situation is unacceptable.  These bookmarks are very, very easily managed with
Netscape 4.77, yet impossible to handle with Mozilla. 

Another test, scrolling from the start of the bookmarks, to the end, takes
_thirty two_ seconds.  That's right, it takes me almost a minute to scroll
through my bookmark list.  Both of these tests were done on a PIII 800 with over
1/2 a gig of ram.  How is a celeron 400 going to react?  I imagine it would take
it upwards of 10 seconds to load my bookmarks initially.  Looking at the CPU
usage when I scroll though the bookmarks makes me think that CPU would become a
limiting factor in scrolling around the PIII 500 stage.

So, let me summarize :

1) the initial opening of bookmarks is very slow and CPU dependent.  A PIII
800mhz should not take 2 seconds to open a bookmark list, even if the bookmarks
number in the tens of thousands.

2) scrolling through bookmarks is exceptionally slow.  I have a 1200 pixel high
screen, so one can only imagine how my tests would have gone if I had an 800
pixel high screen.  It should not take more than a second to access all of my
bookmarks, something which I could do with Netscape 4.77 and this same test
bookmark list.

3) whether or not the bookmark tool in the sidebar addresses some of these
issues isn't important.  Many people do not like it, and one obvious reason is a
space issue.  The sidebar takes up valuable real estate.  When open, it needs to
take approximately 1/3 of my window so that I can actually read most of the
title of the web page.  Obviously quite a few people don't like this.  One
person complaining here is in reality the equivalent of thousands of
dissatisfied customers.  Most have no idea where to complain, or even car about
a web browser enough to bother (they just switch to another).

In short, Mozilla needs an overhaul and optimization of it's bookmark code.  It
needs it now.  

Neil's suggestion is helpful, but it won't fix a few problems.  Firstly, for you
to scroll you must move to the very bottom or top of the bookmarks column.  This
is quite annoying.  Furthermore, if you scroll too far, you must move the entire
length of the screen to scroll in the opposite direction.  Two things would make
this more usable to me.

1) At the top and bottom of the bookmark pane, have an up _and_ down scroll
button.  Firstly, this will allow you to scroll up and down without moving the
mouse.  If you scroll past a bookmark you want, you can scroll back to it
without moving the entire height of the screen to do so.  Secondly, by adding an
opposite button to each existing button, you allow those that are used to the
current behaviour to keep their habitual behaviour.  The top and bottom of the
bookmark panel will still scroll up and down, but has added functionality to
reverse the direction.

2) A tool to configure the speed of the scroll would be great, but with a few
important notes.  

	a) if the tool allows you to configure the bookmarks to scroll one "Page" at a
time, then effectively the bookmark pane will be a single representation of the
multiple bookmark pane method from Netscape 4.7!  One click, and you are on to
the next pane full of bookmarks!  
	b) faster scrolling won't solve other issues, since it is difficult to know
where you are in the bookmark list, directly proportional to the speed with
which it scrolls.  a) solves this
	c) a nice addition would be a set of buttons at the bottom of the bookmark
list, letting you go to pane 3 or 10 or 2 with one click 	  

Comment 50

[[e-mail]]

I would have suggested some (extra?) scroll by page controls, but unfortunately
there are too many NS_ERROR_NOT_IMPLEMENTED in nsScrollBoxObject.cpp :-(

Comment 51

[Arthur]

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

Comment 52

[John Levon]

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

Comment 53

[Pierre Chanial]

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

Comment 54

[Brad Barnett]

I find it very interesting that the font selection pane is scrollable a page at
a time with the mouse wheel, but the bookmark menu isn't.

Obviously bookmarks are of a higher-impact to the end user than the font
selection menu.  Considering the fact that the code is already implemented and
done, why not fix this two year old bug, as well as others that go back 3+ years
(such as the incorrectly resolved and closed 11586).  I don't know of anyone,
when queried, that has more than a pane of bookmarks and is happy with the
current fix.

Hello?  Broken bookmarks for 3+ years?  Anyone home?

It seems not!

Comment 55

[Brad Barnett]

PLEASE FIX THIS ASAP

Comment 56

[Pierre Chanial]

spam is useless.
Please don't change the target milestone unless you plan to fix it.
Resetting priority and tm.

Comment 57

[darinf]

FWIW, the way very long menus are handled on the Macintosh platform has always
been very effective. It seems to resolve all these problems, I think. 

The menu has scroll arrows at each end of the menu, 

It is all one "column" meaning one menu.

The speed is adjustable based on how close the pointer is to the edge of the
screen. I think it's at least 3 speeds, maybe up to 5. When the pointer is
jammed all the way to the edge of the screen, scrolling is at maximum speed. If
you go past an item you want to grab, you can go back to the other side of the
screen at the top (meanwhile the scrolling has stopped) and simply don't move
the mouse all the way to the edge the screen. The menu will then start to scroll
very slowly, and pick up a little bit of speed as you move the pointer closer to
the edge of the screen. This gives you a very high degree of fine-tuning the
scroll speed, so you can "zero in" on the menu item very easily without scooting
by it all the time. 

Hope this helps. 

Darin

Comment 58

[Jesse Ruderman]

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

Comment 59

[Robert Wall]

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

Comment 60

[Michael T. Babcock]

I would like to add to this by saying that on XP at least, when you view the
bookmark list from the bookmarks menu, the scroll-button at the bottom/top of
the list (intended to be mouse-overed) is not near as effective as actually
coding a real scrollbar into the menu (on the right, like a dialog).

Comment 61

[gcthar]

I just started using mozilla last night, I do not like the way bookmarks are
handled. One column is not enough space for me (or others). Scrolling to the
bottom of this column takes far to long. 

I like the way that Netscape 4.7 handles bookmarks. There is a maximum of three,
non overlaping, columns. At the bottom of the third column is a "More Bookmarks"
item; clicking on the "More bookmarks item takes you to the bookmark manager.

I have many of my bookmarks organized into folders. These folders alone take up
more than one column. If I was to further nest these folders I would run into
overlapping menus (I believe this happens after nesting three folders inside
eachother) I would prefer to avoid overlapping menus.

Mozilla seems to be a great program, with lots of cool stuff. I do not
understand why there is so much resistance to changing the bookmark handling
when so many people would like it changed. This is the only complaint I have
about Mozilla, however, it is a big complaint; I can not use Mozilla in its
present state.

Comment 62

[Adrian]

I am still experiencing this bug in Mozilla 1.2 alpha. I have some extremely
long bookmark lists and in order to scroll down in them I have to move my mouse
pointer off and on the down arrow to view an extra 2 to 3 bookmarks at a time.

Strangely enough, moving my cursor to the up arrow works as intended,
automatically (and rapidly) scrolling to the top of the list.

Lastly, regardless of where I am in my bookmark list.. if it's large enough to
warrant those scroll up/down arrows, they are displayed no matter where I am in
the bookmark list. If I'm at the very top, it still displays the scroll up arrow
which I then can move my mouse pointer over and will indent, making one assume
that there's more to be had even though it already is at the very top of the
bookmark list.

Comment 63

[RogerWilco]

Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2b) Gecko/20021016
Mac Powerbook G3 2000, OS 9.2.1, Modern theme

Uncontrollable scrolling here too. Widgets at top and bottom of menu have no
effect on scrolling speed. My bookmaarks file is currently about 500K. Hard to
believe this has been a continuing problem since July. C'mon! Please!

Comment 64

[r]

Ok, after two years of ranting, accusations and insults, I'd like
to summarize and propose things which might lead to a solution of this bug:

1.)
Scrolling menus are *never* and ideal solution, not
only within the bookmarks menu. A menu starts scrolling when it containts
more items than screen space allows. I strongly believe there is always
some way to organize functions/data/whatever to avoid such crowded menus.
Scrolling menus are especially worse, because up/down are far apart,
you can't get quickly browse the menu up/down. Imagine webpages would
be scrolled like that. Please consider also the usability aspects that led
to the invention of Radial Context menus on mozdev.

2.)
Referring to the proposal: WONTFIX - You just have to organize your bookmarks
better and keep them in folders.
I think this isn't a valid argument for this bug, because:

Who should use the scroll-function? People with few bookmarks/folders
don't have one. People with many bookmarks/folders shouldn't use it,
because it scrolls to slowly. Remain the ones who have medium sized
bookmark lists. So does this mean: People with medium sized
lists should be gently forced to organize their lists by giving them
an increasingly annoying "feature"? I hope not.

- Everybody uses bookmarks in a different way. I know of a lot of people
in my company including myself who save a bookmark whenever they come across
something they *might* use/need later just like a "selective" history. Things
are much easier to find in such a "selective history" because not every single
page is saved but only pages really considered important.
I think this is the most common cause for long unstructured bookmark lists.

Now to solve all this, multiple steps could be taken. I don't want to
open a score of new bugs at this point, because I'd like to see where
the discussion leads us to:

1. Instead of showing a scrolling list, just cut the list and show and
item "More" which opens either the bookmark window (Manage Bookmarks) or 
the sidebar. People with large bookmarks lists will intuitively
learn to press Ctrl+B / F9 whatever the next time so they won't have to
go via the bookmark/more menu item. Perhaps we could show some message
the first time this happens.
2. There should be an option to automatically close the bookmark window
or sidepanel if it wasn't open before after some bookmark is selected.
3. Perfect, but not required, would be some sorting for bookmarks by creation
date to address all those people who use bookmarks like "selective history"
and probably suffer the most from this bug.

Someone with a large bookmark list could then do the following:
1. Press some key combination or in future a button
   (if we have a configurable toolbar / buttonbar)
2. Scroll quickly up/down the list, sort it, search it - whatever we
   build in
3. On Single/Double click, the page is loaded and the sidebar closes again.

Much faster than scrolling through large menus and lot of this
is already implemented. Hope this isn't too difficult to implement.
Sorry for the long post, now the ranting can continue ;-)

Comment 65

[Scott Bradford]

ok, how about this proposed idea:
have a "bookmark sort" which locates the sites on google directory and assigns
them a directory structure that mirrors where they are found on the directory
search catagories.  Some may show up more han once if it fits into more than one
catagory. searching for Mozilla for example brings the catagory to:
Computers > Software > ... > Clients > WWW > Browsers > Mozilla

I kind of feel that organizing in subfolders is better than scrolling or opening
sidebars.  you could always hit Ctrl + B to open bookmark manager as it is now.
 when adding a bookmark an "auto sort" option could pick a folder for you and
also keep it in a recentlyt added list in case you forgot where it is.

Another fix might be to make the "search bookmarks" feature more prominent.
Right now you go to manage bookmarks, and then tools -- > search bookmarks. 
search bookmarrks could be on the bookmarks menu right under the manage
bookmarks option menu or by right clicking on the bookmarks folder on the
personal toolbar(which does nothing right now).  search bookmarks failing to
find results should offer to take the search to the web as we could all use more
bookmarks.

Comment 66

[Richard Barnett]

Although it's not terribly relevant to the original form of the bug, I found
that using theme Orbit 3+1 1.x 0.0.6.2 makes the down-arrow widget at the bottom
of a full-height bookmarks menu work.  (It's also IMO quite an attractive
theme.)  This might be helpful for Adrian (comment 62);  it's also a fix for the
bug I was searching for when I stumbled on this one.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910
Windows XP Pro.

Re the suggestions in comment 64:  maybe users could choose a menu containing
the N most recently added bookmarks and/or the N most frequently visited
(optionally in the last M days) bookmarks, where N is calculated based on screen
size & font height.  I like the idea of a bookmark categorising wizard;  a few
years ago there would have been a .com in that...

Comment 67

[RogerWilco]

Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2b) Gecko/20021016
Mac G3 Powerbook 2000; OS 9.2.1

Re: comment #65: "Another fix might be to make the "search bookmarks" feature
more prominent..."

...or at least better! On my Mac with its 500K of bookmarks I've taken to just
opening the whole bookmarks file each time (Command-B), which is a lot faster
than waiting too long for the menu list which then scrolls uncontrollably
anyway. Anyhow, that leaves me at the "Manage Bookmarks" step. (Command-F)
brings up the Search window. It would be great if any bookmarks found were also
indicated somehow in the bookmarks list. Right now there's no way of knowing
where that bookmark is exactly as the results window shows only the matches. I
often have to search through the whole list to find why what I'm looking for
isn't where I'd thought.

Comment 68

[r]

Now I think we must get to some RFE's we all actually agree upon.
Up until now this bug is only about that we all don't like the
current situation. The google-supported bookmark sorter might be a
good idea, but I don't know if it would actually work sufficently:
If I have subpages, does google categorize them all correctly?
And how can I prevent I don't end up with as much categories as I
had single bookmark items before? Some real world testing is
definitely necessary here and as all this is very complex this
is certainly not something we can realistically expect in the *near* future.
Perhaps as a mozilla add-on at mozdev.
So what can we realistically "expect" here from the mozilla programmers
considering there are hundres of other equally important bugs.
It must be something which can be implemented easily and improves all this
significantly. Can we agree perhaps on this basic approach:

1. Away with those horrible scrolling lists
2. Last menu item in an over-sized list is no longer
   a scroll down button, but a more... button. This button
   opens the bookmark manager
3, Bookmark manager should close automatically after a page is selected,
   because I think if you click on a bookmark you want to see
   the page and not the bookmark manager.

This would close this bug. If people now think they don't find sth.
quickly enough within the bookmark manager, we might open new
bugs, among them type-ahead-find-bar (like in Mail) for bookmarks,
autosorting, whatever. We can discuss all those extensions separately,
but all those things won't happen now, because people are annoyed with
those scrolling menus. Of course, they can already open the bookmark
manager now, but they are confused with the scrolling feature which
doesn't really work well. After implementing this, discussion will
shift to improving the bookmark manager which can finally be a far better way
of organizing large lists than those 4x multi-column menus or scrollbars
or whatever as soon as good search functions are implemented (type-ahead-find)
and so on.
Even #3 (auto-close of bm manager) is not *immediately* necessary.
So the smallest possible step to make way for a better way of bookmark
handling, in my opinion seems to be:

No scrolling, add "more" button/item

This is something which might really be accomplished soon and it's
the basic necessary step. And big solutions usually come in small steps...

Comment 69

[Eric Carlson]

Most important to me: I want my Netscape 4.7x style multi-column bookmark lists
back. It's really sad that I have to limit my lists to around 30 bookmarks each
to stop the scrolling.

I would also like to be able to move bookmarks around and edit them in the
bookmark list, and not have to go to the bookmark editor (which also needs work).

Comment 70

[J Vogel]

[e-mail] wrote:
>Now I think we must get to some RFE's we all actually agree upon.
>Up until now this bug is only about that we all don't like the
>current situation.

I disagree. I believe this bug is (with all noise disregarded) a request for
Netscape 4.x style cascading menus as a user-selectable option. This was
indicated in comment #37 when the bug was last re-opened, and again in comment #41.

As others have pointed out, this bug is flawed, and the discussion shows that. I
wish this bug was written as an unambiguous request for cascading bookmarks.
Unfortunately, all subsequent (and more clearly written) requests for that
feature get marked as a duplicate of this bug, so we're stuck with it. At least,
the fact that clear requests for cascading bookmarks get marked as a dup of this
one makes my point.

I want cascading bookmarks back because multiple columns present more
information at a single glance than any other method discussed. It's just
faster, and for me, was the main UI advantage of NN4 over IE... sad that it was
abandoned. Amen to comment #32.

Comment 71

[stephen hurst]

Re rgpublic's #68, the idea of summing up what most could agree on is laudable,
but the assessment is a little off. Points #1 and #2 would make it only
partially like N4.7. And #3 I emphatically disagree with. Post #68 is the first
suggestion of automatically closing the bookmark manager after a bookmark is
clicked (something similar but less radical was suggested in #64), so it can
hardly be said to represent views of many here.

And if that were implemented there would be *many* users calling it a bad bug
and wanting it fixed immediately. If I open bookmark manager, I expect it to
stay open until I close it! (Thank goodness the preferences UI isn't like that;
you'd have to keep opening it over and over to make settings.) The argument for
it was "I think if you click on a bookmark you want to see the page and not the
bookmark manager." Well, you do see the page and not the bookmark manager: the
opened window takes focus and the bookmark manager goes behind. You can toggle
and close the manager if you want to, or leave it open if you want to. Anyway
that suggestion is a digression from this bug.

J Vogel in #70 is right. There has been a consensus lurking in this bug from the
beginning and it is: "Make it like NN 4.7!"

The NN 4.7 bookmark UI is intuitive, quick & easy to use, and should replace the
scrolling list which is so probematic for so many. (I can report that it's
inconvenient and slow to have to scroll even for someone like me who doesn't
even have a large number of bookmarks - just a few more than will show without
scrolling.)

The only actual reasons offered for the insistence on the scrolling UI, AFAICT,
are the three in #24. The first two - "it would cause confusing overlap of a
menu with its own submenus, it would suggest a discontinuity between adjacent
items where no such discontinuity existed" - I do not understand at all. I mean
I can't even tell what he is talking about (what overlap? what discontinuity?
Just look at N4.7). The third reason, "it would have nowhere to go once you got
to the edge of the screen", is of course erroneous as has been pointed out above.

So I support #32, #46 and #70 - make it like N4.7. And as someone said (can't
find citation right now), each post here represents many users who are not aware
of Bugzilla, or simply abandon Moz because of things like this.

Comment 72

[RogerWilco]

Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2b) Gecko/20021016
PBG3 2000, OS 9.2.1

I've got 13 folders on my Personal Toolbar. Last week I discovered I could
simply drag any item from my huge bookmark list directly to one of these folders
instead of using the failure-prone cut/paste method within the bookmark mgr,
closing its window and, fingers crossed, opening it again hoping to see my moved
bookmark where I'd put it. Now maybe this is common knowledge to many of you,
but it was new to me, and I offer it as one way to help someone else survive
this long-lived design crisis. 

NC4.7x? It had no way to manage bookmarks efficiently, so I'm not for simply
going back to that with no meaningful changes. In fact, I've had a stripped-down
version of NN3.0.4 in my machine for a long time simply because it's so good at
simply alphabetizing the gargantuan bookmarks.html file for NC4.8. So far I
haven't had to use it once for Zilla--which started its life off here with the
same file, grown considerably since then. So the current arrangement isn't
totally worthless as-is, but it's still a real pain to use.

Some have said this bug is flawed and so we're stuck with it. Sounds like a
procedural rule change is called for to unstick us then. Surely it's within your
powers, powers-that-be! 

Such daunting bookmark problems in any internet browser...well, I quote S. Hurst
in (#71): "[E]ach post here represents many users who are not aware of Bugzilla,
or simply abandon Moz because of things like this."

The fact that this bug hasn't yet even been given the priority it should have
had all along simply amazes me.

Comment 73

[Eric Carlson]

Where are all the 3rd party add-ins, like better bookmark managers, like we used
to have in the "good" old days?

Comment 74

[stephen hurst]

Re RogerWilco's #72: "NC4.7x? It had no way to manage bookmarks efficiently, so
I'm not for simply going back to that with no meaningful changes."

What I meant by saying let's agree on a N4.7x solution was not to replace the
whole bookmarks apparatus. Rather it was *only* in regard to the scrolling thing
and what happens when you click on Bookmarks in the menu. Certainly let's keep
all other improvements that have happened since the 4-series, including for
example the improved Personal Toolbar that you mention, &c.

Comment 75

[r]

Further comments:

If this bug is about getting back 4.x functionality only,
then change the summary accordingly, but I think it's not useful to keep
looking back. And if the number of bookmarks is high enough, the usability 
problem is still there. Mozilla isn't about doing it somehow, but doing it
right. For people using the internet a lot, bookmark *management* is extremely
important. So finding bookmarks quickly, navigating to bookmarks
with the least possible number of clicks, organizing them automatically
(like someone propose here) - all this belongs to this topic.
So it think its scope is far beyond calling for 4x functionality.
And if there was a really efficent way to find bookmarks even if there
are 1000s of them - then a lot less people would be calling for
4x functionality. I think about a separate bookmark find bar, like
the find bar in mail, I think about hotkeys, sorting, bookmark keywords and
so on. Before a flood of complaints about one of these issue come in:
I do NOT think it makes sense to discuss any of these proposals at
this point. I just want to demonstrate that there can be not equal but
better solutions to the "bookmark mess" problem. Now we have to decide where
all this leads us to. If necessary we must split this bug into two parts:
This one for 4x behaviour, a different tracking-/multi-bug for issues
of efficiently organizing large bookmark lists. Obviously, both bugs
could be FIXED, but because there seems to be much resistance against
going back to 4x, a real evolution of the bookmark management is blocked
as these issues are right now entangled in this bug and chained together.
The summary should as soon as possible be changed into something 
meaningful: Not "...is not optimal", but "4x behaviour for bookmarks".
After that we can file a separate bug "Improve bookmark retrieval".
I hope this will be something even the 4x-fans can agree upon.

Comment 76

[RogerWilco]

Frankly, at this point, just making what we already have work properly as soon
as possible would be a nice step--meanwhile the discussion can go on as to how
many bugs #45700 can be turned into to help the work actually go forward. Two,
three? Please, someone take charge and begin to lead Moz out of this seemingly
endless morass! 

Comment 77

[Brad Barnett]

Bookmarks have been partially fixed, but are still inadequate when it comes to
large bookmark lists.  My bookmark list is about 6 or 7 panes in netscape
currently, but it takes about 30 seconds to scroll through it with mozilla.

The problem _was_ fixed, when bookmarks had a scrollable bar ... allowing you to
_quickly_ scroll through them.  Even better, you could use your wheel on a wheel
mouse to zip through them with ease.

I really feel that the current state of the bookmark list is almost as useless
as _not_ having a scrollable list at all!  30 seconds is way, way too long to
wait to scroll through the list, and having to move all the way to the bottom of
the list, or top to do so is unacceptable.

Please fix this horror.  Please.

Comment 78

[[e-mail]]

Mousewheeling through bookmarks menus is bug 97787 but so far I've failed to
convince the module owner to sanction this non-standard behaviour :-(

Comment 79

[Robert Mohr]

Removing mozilla1.1 keyword (I don't think it was fixed by then).

Comment 80

[Yukinoroh[:Yukinoroh]]

Could Mozilla at least have an option to make bookmarks behave like Netscape
4.x, while keeping the actual behaviour as the default one? This could allow
users with large bookmark lists like Brad and I to finally get some
satisfaction. Actually, Konqueror has that capability (without leaving the
choice to the user though), so I believe there is a need for it...

Another solution would be to make the auto-scrolling buttons smaller and to move
them at the right of the list. Mozilla remembers what item your mouse was on
last time you used the bookmark list, so quite often, when I reopen the list, my
mouse passes over the auto-scrolling up button, and the list goes up without
asking. It's very annoying...

Comment 81

[Mats Palmgren (inactive)]

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

Comment 82

[James B. Higgs]

When there are more bookmarks than will fit in a column, I would prefer that
that they display in a multicolumn fashion instead of seeing "scroll arrows" at
the top and/or bottom of a single column. I feel that this should be configurable.

Multiple columns should be displayed, similar to setting StartMenuScrollPrograms
to "NO" in HKLM\Software\Microsoft\Windows\CurrentVersion\explorer
and HKLM\Software\Microsoft\Windows\CurrentVersion\explorer\Advanced
in the Windows Registry.

Comment 83

[James B. Higgs]

As for having more columns than will fit on the screen, add a "Left Arrow" scroll
control to the left side of the multicolumn display, and a "Right Arrow" control
to the right side, to scroll one *column* at a time instead of one *bookmark* at
a time.

Comment 84

[Kenny Leong]

There is a bug that definitely needs to be fixed with bookmarks. It seems that the programmer or coder forgot to put something in the user interface for the bookmarks dropdown list.

The glitch is observed for a long bookmark list (eg more than 50 entries perhaps) by following this procedure....

1. click on Bookmarks so that the bookmark dropdown list appears
2. use the mouse to hover over one of the bookmark entries so that the entry becomes highlighted.
3. Now leave the mouse alone so that the bookmark entry remains highlighted. Do not touch the mouse anymore.
4. Now use the down-arrow key to scroll through the bookmarks list. You will find that the down-arrow key will not be able to scroll through the ENTIRE bookmarks list. Instead, you will only be able to scroll through whatever is currently visible in the drop-down list. And the scrolling just rolls back to the beginning or end of the list. But the point is, it does not behave properly in that pressing the down-arrow key repeatedly will not let you scroll through the entire bookmark entry list.

Actually, I don't think the above is really a bug. It is just something that the coders or programmer forgot to handle.

Comment 85

[Kenny Leong]

oops... I forgot to say that the above is in relation to firefox browser.

Comment 86

[gah6]

(In reply to comment #85)
> oops... I forgot to say that the above is in relation to firefox browser.
> 

This bug may stray from the original intention of this thread, but it's legit.  I just tested the steps in comment #84, and it's fully repeatable in Seamonkey 1.1.2 as well...

Comment 87

[Roman R.]

This problem is still as it was when it was reported in 2000. Having a scrollbar would be an ideal solution, in my opinion. But the sidebar provides that.

Comment 88

[:Hb]

Severity to Enhancement

Comment 89

[Steve]

(In reply to comment #87)
> This problem is still as it was when it was reported in 2000. Having a
> scrollbar would be an ideal solution, in my opinion. But the sidebar provides
> that.

Or just ADD multi column bookmarks like other browsers have. The is a plugin called "Column Bookmarks FF3 0.2" but it doesn't work well with newer versions of FF. This is a SERIOUS oversight for the modern world as peopel tend to have more than a few bookmarks these days that they don't really want to make extra folders for.

Comment 90

[Phoenix]

Now, with scrolling with mouse wheel available after Bug 97787 was fixed and large screens able to show a couple of dozens bookmarks at once, is this bug still actual?

Comment 91

[:Hb]

(In reply to gah6 from comment #86)
> ... I just tested the steps in comment #84, and it's fully repeatable in Seamonkey 1.1.2 as well...

That is a misuse of two different user interfaces with contradicting commands.

The bookmarks menu should behave like all other menus on a system. A different mechanism would confuse more than it would do good. 

I agree with OP in "large bookmarks list aren't ideal" but giving up the scrolling menus is the wrong solution.

I recommend: Won't fix.

Comment 92

[Brad Barnett]

ROTFL.

Comment #90 -- the bug is not fixed.  Maybe you should read the full initial bug report first?

I *have* to be a little cynical here, after all, when someone starts talking about how the bug might be fixed, even though the bug report delineates ways it is not fixed.. AND THE BUG IS 12 YEARS OLD.... well...

One might get a little perturbed.

So, for starters, no... the bug is still there.  As mentioned in this bug report and bugs it references.. the scrolling method is PRECISELY the problem... it isn't a fix, but the issue!

It still exists in Firefox, a whole new branch.  It's still in Mozilla too.  Note, when this bug was opened 12 years ago, the bug existed everywhere.  I can only currently confirm that it exists with Linux.. and after 12 years, I think it would be a little silly to expect me to do checks on all OSes to validate what has never been fixed.

(initially I tested under Windows to see if the issue was there as well)

Further, the problem is *worse* now, as we have notebooks out there with super-wide, but not-very-high screens.  Say again, this problem is *worse* now, with modern 16:9 or 16:10 screens.

As well, scroll support is actually completely broken now, at least on the Firefox branch.  My scroll wheel either scrolls (with one movement) to the very end or start of the bookmarks.  My other option is to move the mouse to the up and down arrows at the top or bottom of the bookmark list, and wait (still, 12 years later!) at least 30+ seconds to scroll to the bottom of my bookmarks.

Further, the last statement is taking a statement in comment #86, which is actually a subset of this bug (or, even a different bug).. and, using it to state that the entire bug is invalid?  Or, are you only referencing comment #86?

Guys.. when there was a scroll bar on the menu -- nothing was more intuitive.  Users are completely used to that concept, it is absolutely not confusing, and it would resolve the bug completely.

Any user knows that a scrollbar = you can grab it to scroll.

Comment 93

[Phoenix]

(In reply to Brad Barnett from comment #92)
> As well, scroll support is actually completely broken now, at least on the
> Firefox branch.  My scroll wheel either scrolls (with one movement) to the
> very end or start of the bookmarks.  My other option is to move the mouse to
> the up and down arrows at the top or bottom of the bookmark list, and wait
> (still, 12 years later!) at least 30+ seconds to scroll to the bottom of my
> bookmarks.
This bug report filled against SeaMonkey, I just checked, 700+ bookmarks (which is insane, but created for test purposes) are scrolled with wheel in just 10 seconds from start to end of list.
If there are some scroll issues in Firefox, you should fill separate bug for them.

> Any user knows that a scrollbar = you can grab it to scroll.
If you need scrollbar, who disallows you from opening Bookmarks Manager and using scrollbar there?

Comment 94

[Steven Gorsky]

> The bookmarks menu should behave like all other menus on a system. A
> different mechanism would confuse more than it would do good. 
You can't really say it's different since there are no other menus that can end-up long enough to cause a difference, and if there were you would end-up with a different usability problem.

Part of the complaint is that back in the Netscape Navigator days the bookmarks drop-down did break into multiple columns when necessary, and when this bug was reported it was considered a regression. Scrolling through bookmarks and folders of bookmarks (mouse wheel or not) is a pain when you have a lot of them, and using Show All Bookmarks doesn't help at all as you either still scroll or you have to search. With the multiple columns you can just grab the one you want. On Windows the Start Menu works this way either by default or through a minor registry edit. At the very least allow people the option to select what they prefer - even if it's hidden and need to be done through about:config.

This bug has been open since Mozilla was still in beta, and the product field at the top is outdated as this problem also now applies to Firefox (I can't edit this myself).

Comment 95

[Brad Barnett]

Yes, this bug was about Seamonkey, which was Mozilla at the time.  Of
course it wasn't against Firefox, Firefox did *not* exist in 2000.

Heck, this bug is actually pre-2000, going back to bug

https://bugzilla.mozilla.org/show_bug.cgi?id=11586

Regardless, Firefox was split from Seamonkey.  Clearly, it inherited all
bugs.  You should really just clone this bug.. or add Firefox to it.
That should have been done when Firefox was split.

Still, I find it amusing that the same old comments come back a decade
later.

Even more amusing is that clearly, this bug is so old, has sat so long,
that people are not even able to understand the context of this bug.

Why?

Well, because this bug related to the fact that Netscape handled more
than one pane of bookmarks correctly, and Mozilla did not (and, Firefox
inherited this bug).  Without using Netscape, you would never understand
how horrible the new functionality is.  See 11586.

It is a horrible kludge, a usability nightmare.

I could easly have *thousands* of bookmarks, and get to them simply and
without issue, and instantly under Netscape.  Mozilla appeared, and the
bookmark menu system was destroyed -- and never properly fixed.

(Note: as I'm sure you know, Mozilla was released under the Netscape name
too -- clearly it makes sense for people to say "Arg!" when an updated
version of their browser suddenly borks on their bookmarks, after working
for 7+ years with them)

Sure, you can say "use this instead".  However, that's not really the
point, is it?  There is a menu item, it is called 'bookmarks'.  The menu
item is broken, if you have more than 50 bookmarks.. eg as soon as you
need to scroll.

So, please, stop the deflection.  Deflections such as:

- this bug is so old, the codebase was forked -- open the bug elsewhere!
- this bug wouldn't show itself, if you didn't use the bookmark menu --
  try using another way to use bookmarks!
- the bug wouldn't be a problem, if you didn't bookmark so many sites!
  Why do you use the bookmark feature so much!  Stop it!

This menu item has a bug.  It's been around more than a decade.  It has
stood the test of time, it still exists, and closing it now is
essentially just letting it slide... and leaving Mozilla and Firefox with
a usability nightmare.

Note: I find it really amusing that this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=37648

States --> "This bug is a dupe of very ancient bug 11586 which has been
properly escalated."

And, that was in 2000 as well. :P

Note: yeah.. I'm pushing the envelope on the rant/rude side of things,
but it's very, very hard to stomach people coming into an issue that's
been around since 1998 really -- and, just trying to brush it under the
rug.

Even under the rug, the dirt will still be there!  Hiding it doesn't make
it go away!

Comment 96

[Ben Bucksch (:BenB)]

Several pages (i.e. expand in x axis) would still be more efficient and usable, because you can see more at once. With scrolling, you have no overview.