Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001024 Netscape6/6.0 on WinNT 4.0 SP4 I have *many* bookmarks, and *many* folders with sublists of bookmarks. (Enough total bookmarks and folders in the top-level bookmarks list that it scrolls *way* off the bottom of the screen.) Currently, I'm unable to access the bookmarks in the folders which are more than halfway down the list. Reason? It turns out that the code that is calculating where on the screen to display the second-level submenu of bookmarks (i.e. the bookmarks that are contained in a top-level bookmark folder) has an increasingly large error the further down the list you go: 1) if the folder is on the first page-height of bookmarks, the submenu displays just fine, and just to the right of the bookmark folder as you would expect 2) if the folder is on the second page-height of bookmarks, you notice that the submenu displays at a position on the screen that is vertically offset from where it should be; the X position of the submenu is right (just to the right of the first-level bookmarks list), but the Y position of the submenu is closer to the top of the screen than it should be 3) the further you go down the top-level list of bookmarks/folders, the worse the problem gets, until ultimately you see just a 1-pixel-wide sliver of the bottom of the submenu along the top of the screen, and ultimately you see nothing at all This renders the bookmarks in those subfolders inaccessible. Reorganizing your bookmark list to have more deeply nested folders (and thus a shorter top-level list) *might* be a workaround, although I haven't tried this. This is a serious problem for anyone who has a long list of bookmarks. If you want to see the problem reproduced, drop by my cube.
4.x displays bookmark lists of this length without trouble.
Another workaround is to go into the Manage Bookmarks UI and manually copy the URL from the desired bookmark's edit dialog into the browser URL bar.
Should be considered for rtm, rtm keyword
Ben, what would it take to fix this, and how risky would a fix be? I am concerned because our opinion leaders of Netscape 6 are heavy bookmark users and will run into this problem. For these people, this is similar to saying that mail can not support more then X number of folders or messages.
I've seen this problem also on my machine, where I have a large list of bookmarks, and a subfolder near the base of the folder for IE favourites, which positions itself incorrectly up the screen. I think this is a menu bug. Reassigning to pink for evaluation, I can send you my bookmark file.
Assignee: ben → pinkerton
benG: can you attach your bookmarks file?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
rtm-. Although I'm one of the heavy bookmarks users (it takes me several minutes to scroll to the bottom of my bookmarks menu, and I have to collapse the Windows taskbar to get it to scroll at all!), this is not high-benefit relative to hundreds of other bugs we still have that affect *all* users.
Going to try and produce a patch for this. I think I've figured out what's going on.
I have a patch, will attach with explanation shortly...
Pink, can you take a look at this? Copying hyatt, who can super-review. Here's my explanation. Excuse my lack of knowledge of the right terminology. So here's how I understand the positioning system of submenus to work: 1) obtain the position of the containing menu's view (e.g. for a bookmarks submenu, obtain the position of the bookmarks menu itself) 2) add to this coordinate the offset of the submenu frame from the view's origin, and add the width of the containing menu's view. 3) perform other stuff as required (edge of screen bumping, etc). The problem seems to be this: the offset of the frame from the view is the distance between the frame and the top of the containing menu. In most cases (non-scrolling menus) this does not matter, as all of the menu is always onscreen. In the case of a scrolled menu, like a long bookmarks file, or a personal toolbar folder rooted on, say, a sweetlou directory, much of the distance bwetween the origin and the coordinate returned by nsFrame's GetOffsetFromView is offscreen, and should not factor into menu positioning calculations. nsIView's GetBounds method returns a nsRect that contains the top and left coordinates of the scrolling view. In the case of a scrolled menu, the top (y) field is negative. Adding this to the offset coordinate yields the correct y position for the submenu. This is what this patch does. Also, I added a check in GetViewOffset to prevent the scrolled view's negative y bound from interfering with returning the correct position of the containing menu.
[reassigning to myself]
Assignee: pinkerton → ben
Status: ASSIGNED → NEW
*** Bug 44055 has been marked as a duplicate of this bug. ***
This is a toolkit issue. Resetting component, updating QA contact and copying pink ;)
Status: NEW → ASSIGNED
Component: Bookmarks → XP Toolkit/Widgets: Menus
QA Contact: claudius → jrgm
looks ok to me, i guess. r=pinkerton
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Reopening. There appears to have been a problem with this fix when checked in and the fix has been removed. I'm looking into it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Fixed checked in again. Hyatt has fixed the problem that was causing the incorrect positioning.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.