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

RESOLVED FIXED in mozilla0.9

Status

()

P3
normal
RESOLVED FIXED
18 years ago
10 years ago

People

(Reporter: ekrock, Assigned: bugs)

Tracking

Trunk
mozilla0.9
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm-])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
4.x displays bookmark lists of this length without trouble.
Keywords: 4xp
(Reporter)

Comment 2

18 years ago
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

18 years ago
Should be considered for rtm, rtm keyword
Keywords: rtm

Comment 4

18 years ago
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

Comment 7

18 years ago
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.
Whiteboard: [rtm-]
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...
Created attachment 19472 [details] [diff] [review]
patch to fix this bug (phew)
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

Comment 13

18 years ago
*** 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

Comment 16

18 years ago
a=hyatt
Fix checked in. 
actually fixed. 
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 ago18 years ago
Resolution: --- → FIXED

Updated

10 years ago
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.