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.

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

reopened 11586, and closing this bug *** This bug has been marked as a duplicate of 11586 ***

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.

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.

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.

[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

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.

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

m19

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.

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.

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

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

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 ***

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

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.

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 ***

"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

reassigning to component owner and changing summary.

Triage Team marking nsbeta1-

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...

updating to new owner. sorry for the spam.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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

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 nobody@mozilla.org.

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.

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

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.

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.

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.

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

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

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

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

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.

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

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

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

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

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

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

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

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!

PLEASE FIX THIS ASAP

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

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

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

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

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

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.

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.

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!

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 ;-)

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.

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...

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.

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...

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

rgpublic@gmx.net 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.

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.

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.

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

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.

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.

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!

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.

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

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

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...

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

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.

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.

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.

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

(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...

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.

Severity to Enhancement

(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.

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?

(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.

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.

(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?

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

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!

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.