57951 - contents of Bookmarks folders display above top of screen and cannot be accessed

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[ekrock's old account (dead)]

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.

Comment 1

[ekrock's old account (dead)]

4.x displays bookmark lists of this length without trouble.

Comment 2

[ekrock's old account (dead)]

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. 

Comment 3

[johng]

Should be considered for rtm, rtm keyword

Comment 4

[johng]

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.

Comment 5

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

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.

Comment 6

[Mike Pinkerton (not reading bugmail)]

benG: can you attach your bookmarks file?

Comment 7

[Peter Trudelle]

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.

Comment 8

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

Going to try and produce a patch for this. I think I've figured out what's going 
on. 

Comment 9

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

I have a patch, will attach with explanation shortly...

Comment 10

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

Attachment: patch to fix this bug (phew)

Comment 11

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

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. 

Comment 12

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

[reassigning to myself]

Comment 13

[John Morrison]

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

Comment 14

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

This is a toolkit issue. Resetting component, updating QA contact and copying
pink ;) 

Comment 15

[Mike Pinkerton (not reading bugmail)]

looks ok to me, i guess. r=pinkerton

Comment 16

[David Hyatt]

a=hyatt

Comment 17

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

Fix checked in. 

Comment 18

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

actually fixed. 

Comment 19

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

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. 

Comment 20

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

Fixed checked in again. Hyatt has fixed the problem that was causing the 
incorrect positioning.