Closed Bug 124485 Opened 22 years ago Closed 22 years ago

Long lists of folders/bookmarks after up/down arrow not reachable

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: olgam, Assigned: kinmoz)

References

Details

(Keywords: access, regression, Whiteboard: [driver:dbaron])

Attachments

(2 files, 2 obsolete files)

Build: 02-08-2002

Overview: Can not proceed to long lists of Bookmarks, folders in
Message|Copy/Move - when use mouse.

Steps to reproduce: I noticed it first when trying to reach my Bookmark created
yesterday and sitting at the end of the long list. Then from 3-pane window I
tried to move a message to the folder, which also resides on the list after the
down arrow. I was not able to move that message by using mouse. 

Actual Results: Can not go farther then displayed arrows on the list of
bookmarks or folders.

Expected Results: Bookmarks or folders are reachable while navigating by mouse.

Additional Information: Keyboard navigation by arrow keys works. Started seeing
it on 02-08-2002 build - 02-07 build did not have this problem. Usually it was
not smooth, it required some repetitive movements of the mouse around 'down
arrow' - in order to see next folders.
I see it on Linux and Win2K.
I noticed something new: when move mouse upper the 'upper arrow' in the
Copy/Move list of folders, I see "File Here". If I click on this, I get warning:
"The current command did not succeed. The mail server responded: Mailbox does
not exist."
What is it? I don't recall, I saw it before.
Keywords: regression
QA Contact: esther → olgam
hey pink, d'you perchance know of any recent regressions in XP Menu Land that
might be related to this?
*** Bug 124640 has been marked as a duplicate of this bug. ***
When verify: to check Search Messages dialog, folders drop-down list with cascades.
Nominating for nsbeta1 and upgrading severity. I cannot use effectively Mozilla
until this is fixed as I have long bookmark lists.
Severity: normal → major
Keywords: nsbeta1
There is Browser/Bookmarks related bug 124542.
With build 02-14-2002 we can not proceed even with keyboard.
sounds like this is a generic menu problem.  Reassigning.
Assignee: sspitzer → hyatt
Component: Mail Window Front End → XP Toolkit/Widgets: Menus
Product: MailNews → Browser
QA Contact: olgam → jrgm
Olga: I am running Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8+) Gecko/20020214
and am still able to scroll with arrow keys even though the mouse can't do it.
*** Bug 124542 has been marked as a duplicate of this bug. ***
This regression affects keyboard navigation in the url bar dropdown, makes it
impossible to reasonably change default fonts in preferences, etc.
Keywords: access, mozilla0.9.9
roc: have there been any view manager changes recently that could have caused this?
i'm seeing this on mac with long bookmark lists on the personal toolbar. It's
even happening _before_ the scroll point. after a certain point, i don't get any
mouse rollover feedback in the menu. It's as if it's being clipped out. Clicking
the bookmark works fine.
The view manager is delivering the mouse events to the presShell correctly, as
far as I can tell.

nsPresShell::HandleEvent appears to be adjusting the event coordinates in a
bogus way before passing them to GetChildFromPoint. What's weird is that the XUL
frame for the menu popup has origin (0,0) but its view is clearly not at (0,0).
I think this is causing the adjustment to get screwed up. The menu popup frame's
origin should almost certainly NOT be (0,0).

The bug is especially clear when you have the window at the bottom of the screen
so the menu pops up above the menu bar. Neither of the scroll buttons work
because the mouse event is translated into something with negative coordinates.

Over to you, pinkerton...
From bug 124542, Boris here notes the timeframe of this occurance, & bonsai,
Dean and I made a few guesses to what it might be over there.

------- Additional Comment #19 From Boris Zbarsky 2002-02-11 21:01 -------

Could this be a focus/event issue?

I've noticed 3 things that all worked in 2002-02-07-07 and are broken in
2002-02-07-22:

1)  This bug 124542
2)  Clicking on search engine in the url bar dropdown (it no longer gets events)
    (bug 124740)
3)  Tabbing through <area> elements acts oddly (bug 124789)

#1 and #2 definitely seem related...



------- Additional Comment #20 From Dennis (dman84) 2002-02-12 00:13 -------

Boris,

here is bonsai for 1/7 00:00 to 23:59.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=02%2F07%2F02+00%3A00&maxdate=02%2F07%2F02+23%3A59&cvsroot=%2Fcvsroot
I am 100% certain that this bug was caused (or perhaps, "revealed") by kin's
checkin for bug 83650.
Ok, I feel lame for causing this. But I do have a fix for it! :-)

Apparently, a frame can contain a view that is not in the frame's parent view's
hierarchy.
Assignee: hyatt → kin
Priority: -- → P3
Target Milestone: --- → mozilla0.9.9
Marking nsbeta1+
Keywords: nsbeta1nsbeta1+
Really? That should never happen.
Keywords: nsbeta1+nsbeta1
Attached patch Patch Rev 1 (obsolete) — Splinter Review
This patch returns an offset, only when the frame's contained view is a
descendant of the frame's parent view.
Status: NEW → ASSIGNED
Whiteboard: FIX IN HAND, need r= and sr=
restoring accidentally removed +
Keywords: nsbeta1nsbeta1+
*** Bug 126514 has been marked as a duplicate of this bug. ***
roc+ care to sr=?
I have to admit that I don't understand what this code does or why we need it.
For example, it should always be the case that if a frame and its child have
views, the child's view should be a child of the frame's view. If that's not
true somewhere then I think we should be fixing that.

Likewise, it should always be the case that the delta between view origins is
equal to the delta between the origins of their frames.
> For example, it should always be the case that if a frame and its child have
> views, the child's view should be a child of the frame's view. If that's not
> true somewhere then I think we should be fixing that.

For the record, this is completely wrong and I should have realized that since I
wrote a lot of code to deal with the cases where it's not true :-).
This needs checking in. Do we need an a= at this moment?
Keywords: approval
Whiteboard: FIX IN HAND, need r= and sr= → Needs cheching in, r=kmcclusk@netscape.com and sr=roc+moz
*** Bug 126595 has been marked as a duplicate of this bug. ***
kin, check this sucker in. preemptive a=roc+moz for 0.9.9
The formal way to get this in during a freeze is to get permission from
drivers@mozilla.org ... roc+moz you are a driver right? I know you gave me an
a=roc+moz, but I'll send mail anyways just to follow procedures and inform the
other drivers ... so if you can reply to the email, I can get this in today once
verifications are done. :-)
*** Bug 126682 has been marked as a duplicate of this bug. ***
*** Bug 126830 has been marked as a duplicate of this bug. ***
Fix checked into TRUNK:

    mozilla/layout/html/base/src/nsFrame.cpp  revision 3.364

Should appear in 02/21/02 8am builds.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 126871 has been marked as a duplicate of this bug. ***
This fix isn't working for me.  I can now scroll my secondary folders, but my
root bookmark folder(ie the list I see when I click on the menu "Bookmarks")
still refuses to scroll down properly when the mouse is over the down arrow(ie
either it jumps down one bookmark and stops or does nothing and I have a lot
more bookmarks than that).   I tried it on a new profile with a bookmark file
backup from before this problem arose still with no luck.  I double-checked the
revision number of mozilla/layout/html/base/src/nsFrame.cpp to make sure I had
the fix and got 3.364 as well as "Status: Up-to-date".  The secondary folders
which I am now able to scroll which I couldn't before are all dynamically
generated folders, but unfortunately I don't have any static folders which are
long enough to test whether static secondary folders now work...  I didn't try a
clobber, but it doesn't seem like that should be necessary.  I am on Linux.
Travis, when you picked up the fix, did you rebuild from the mozilla/layout 
directory? I'll try to generate a long root bookmark menu in my build and see if 
I still see the problem.
> I'll try to generate a long root bookmark menu

If you want a quick way, go to prefs and set up tabs to open for control-click
of links, and to open in the background. Then go to any Bugzilla list (such as
QA menu -> Bugs Filed Today). Then hold down control and click on a bunch of bug
links (this will open a bunch of tabs in the background, leaving the bug list
visible). Then go to the far right tab and hold down control while pressing D
and W repeatedly. (Ctrl-D adds bookmark, Ctrl-W closes tab...you can do this
with two fingers). Do this enough and you'll have a long root bookmarks menu.

To make a long non-root folder, open the bookmarks menu (Ctrl-B) and make a
folder. Go to View -> Set as New Bookmark Folder. Then follow the same steps. I
think this will make all the new bookmarks go into the new folder.

These keybindings are Win32, but I think they should be the same on other
platforms. HTH
Ok I see the problem. What I'm seeing is that the frame's contained view *is* a 
descendant of the frame's parent view in the root menu case.

roc any idea why root menu would be different from a submenu in this regard?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
I know next to nothing about menus. You need to talk to pinkerton.
Attached patch Patch Rev 2 (obsolete) — Splinter Review
So it looks like root menus differ from the scrolling sub menus in that the
frame's contained view *is* a descendant of the frame's parent view, *but* the
view's position is *not* relative to the parent view. < sigh >

This patch I'm attatching, looks big, but it's mostly outdenting existing code,
and adding comments and an additional check for crossing widget boundaries
while traversing up the view parent hierarchy.

It's my effort to minimize the cases where I do generate a non-zero (0,0)
offset. I now generate offsets when the view is a descendant of the parentView,
and the view, or any views between it and parentView, don't have widgets
associated with them.

This seems to fix the scrolling menus problem for both root and sub-menus.
Whiteboard: Needs cheching in, r=kmcclusk@netscape.com and sr=roc+moz → FIX IN HAND, need r= and sr=, and testing
I have a feeling this is really a workaround for a bug in the menu code.

I REJECT my comment #28. I was right the first time. We normally have the
invariant that, given two frames F_A and F_B with corresponding views V_A and
V_B, F_A is an ancestor of F_B if and only if V_A is an ancestor of V_B. This is
true even for slightly odd stuff like fixed position frames*. I'm disturbed that
menus don't seem to obey this.

* It is NOT true when you compare the frame and content models, which is where I
got confused.

Under normal conditions I would like to spend more time to have this
investigated and properly fixed. But we do need a fix for this for 0.9.9. Hmm...

I'm going out of town for a couple of days. If you want movement on sr= and a=
during that time you'll need to call on someone else.
*** Bug 127149 has been marked as a duplicate of this bug. ***
FYI, I'm still looking into this problem. I'm currently trying to figure out the 
menu code. There seems to be a difference in positioning between the 
nsMenuPopupFrame and the view it contains ... they are however the same size. 
It's that difference that's throwing off my offset calculations.

Patch Rev 2 does make the one remaining root menu scrolling problem go away, but 
*if* there is a real problem in the menu code, I'd like to fix it there. If I 
take too long and 0.9.9 has to go out, perhaps it could go out with the patch to 
buy me more time.
*** Bug 127308 has been marked as a duplicate of this bug. ***
I was just wondering, what theme is everyone viewing this problem with? because
on my computer I have noticed different behaviours between the classic and
modern themes...
on the classic theme, the down arrow is not completely broken; there is a _very_
small amount of space at the top of the arrow where there is still a bit of
response to mouseover, but in the modern theme, there is no response at all

I've seen no one else mention anything like this before, so I'm assuming that
others have been using modern, while I've been using predominantly classic... 

I don't know if this is contrary to any of the info found already or if it's
helpful, but no one else has commented on this behaviour, just "down arrow
broken", so...

I'm using win98, and just downloaded a new build and I'm still seeing the arrows
this way (it's how I've seen this all along, as well)
james: it's not contrary, it's pretty much what I'd expect. But thanks for
confirming.

kin: I think bug 127211 may have been caused by your changes. My tracing shows
that the events that are sent to the XUL in the IFRAME are being translated by
nsPresShell to coordinates outside the XUL box.
james, take a look at dupe bug 124542, its got some of that I think, I seen this
in classic, weird stuff after it broke and before the patch v1 was landed here.
*** Bug 127487 has been marked as a duplicate of this bug. ***
*** Bug 127501 has been marked as a duplicate of this bug. ***
Want this fixed in 0.9.9 if possible, else 1.0 for sure.

/be
Blocks: 122050
*** Bug 127556 has been marked as a duplicate of this bug. ***
*** Bug 127613 has been marked as a duplicate of this bug. ***
I'm attatching a patch that basically disables the changes I made to fix 83650.


I'm thinking I might check this in for mozilla0.9.9 instead of Patch Rev 2, and
reopen the related bugs so I don't hold anything up, and have more time to sort
things out.

What I'm seeing in the menu code, is that a view and it's containing frame
don't necessarily have to  intersect at all, and that there is an assumption
that any point relative to the view's upper left corner is, without any
translation, also relative to the frame's upper left corner even though that is
not the rendered reality.
*** Bug 127834 has been marked as a duplicate of this bug. ***
Whiteboard: FIX IN HAND, need r= and sr=, and testing → FIX IN HAND, need r= and sr=, and testing [driver:dbaron]
Comment on attachment 71394 [details] [diff] [review]
Patch to disable fix for bug 83650

r=roc+moz

I agree. Let's revert to the old behavior for 0.9.9.
Attachment #71394 - Flags: review+
*** Bug 127992 has been marked as a duplicate of this bug. ***
*** Bug 128047 has been marked as a duplicate of this bug. ***
FYI, I had a talk with brendan and hyatt about this bug yesterday, and it was
decided that we should probably keep the MenuPopupFrame and MenuPopupView in
sync in terms of position. Hyatt suggested doing this at the last possible
moment in nsMenuPopupFrame::SyncViewWithFrame().
*** Bug 128123 has been marked as a duplicate of this bug. ***
So I have some code that syncs the menu popup frame with it's view, and it fixes
the root scrolling menu problem. But as hyatt anticipated there are some
problems with the popup menu widget that uses scrollbars. The scrollbar's
tracking is a bit off, so I'm trying to remove some of the workarounds he said
he added earlier to nsDOMEvent::GetClientX() and GetClientY() and trying to find
a permanent fix for it.

Stay tuned.
Whiteboard: FIX IN HAND, need r= and sr=, and testing [driver:dbaron] → [driver:dbaron]
kin: in case Hyatt didn't mention the bug for that, it's bug 78344.
*** Bug 128485 has been marked as a duplicate of this bug. ***
Attached patch Patch Rev 3Splinter Review
Patch Rev 3 fixes the problem by syncing up the popup menu frame with it's
view, and it also fixes some offset problems in the scrollbar slider frame code
that were exposed by the sync'ing in the auto-complete widget pulldown.
Attachment #70399 - Attachment is obsolete: true
Attachment #70748 - Attachment is obsolete: true
kin, can you get a review of this from hyatt or pinkerton? We'd like this to
make 0.9.9.
*** Bug 128769 has been marked as a duplicate of this bug. ***
FYI, I sent pinkerton and hyatt an email requesting an r=. Once I get that, I'll 
ask for driver approval for checkin to mozilla0.9.9 branch and the TRUNK.
Whiteboard: [driver:dbaron] → [driver:dbaron] FIX IN HAND, need r= and a=
*** Bug 128932 has been marked as a duplicate of this bug. ***
*** Bug 121871 has been marked as a duplicate of this bug. ***
Comment on attachment 72150 [details] [diff] [review]
Patch Rev 3

r=hyatt
Attachment #72150 - Flags: review+
Whiteboard: [driver:dbaron] FIX IN HAND, need r= and a= → [driver:dbaron] FIX IN HAND, need a=
Comment on attachment 72150 [details] [diff] [review]
Patch Rev 3

a=asa (on behalf of drivers) for checkin to the 0.9.9 branch and the 1.0 trunk
Attachment #72150 - Flags: approval+
Fix checked into the MOZILLA_0_9_9_BRANCH:

    mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp  revision 1.151.2.1
    mozilla/layout/xul/base/src/nsSliderFrame.cpp     revision 1.86.10.1


Fix checked into the TRUNK:

    mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp  revision 1.152
    mozilla/layout/xul/base/src/nsSliderFrame.cpp     revision 1.87

Status: ASSIGNED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Whiteboard: [driver:dbaron] FIX IN HAND, need a= → [driver:dbaron]
Fixed on Win2K using 2002030604
How about Mac and Linux?
Fixed on Linux 2002030521 trunk.
Verified on Win2K and Linux on 03-06-2002 trunk build.
Checked mouse and up/down arrows navigation in the long lists of bookmarks or
folders in the areas:
1. Bookmarks
2. Copy/Move in Messages menu
3. Copy/Move in Context menu
4. Search Messages dialog, 'Search for messages in:' drop-down list with cascades.
Status: RESOLVED → VERIFIED
Even fixed in OS/2 2002030616
Fixed in Mac OS 9 (checked font dropdown in Preferences)

Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.9+) Gecko/20020306
I hate to be a wet-blanket, guys, but:
MOZ 2002-03-06-04 on Win98se (4.10.2222)

Situation: I have about 8 "customized" headers in my message filters, making the
choice list longer than usual.

Select Edit->Message-Filters;
Select New, *make sure that box is positioned near the bottom of the screen*.
Drop down the header-selection list in Message Criteria.

OBSERVED: If the list is long enough to intrude on the Windows Task Bar or
beyond the maximized Mozilla window it is not possible to get to the bottom
selections.  Even the keyboard arrow keys cannot get there.

There is a work-around, of course, by re-positioning the parent Message Criteria
box higher on the screen.

EXPECTED: Either (1) a scroll-arrow at the bottom of the list, providing access
to the items chopped off by the screen edge, OR (2) "un-pin" the top of the list
from the drop-down label so that the entire list fits within the screen.  If the
list gets "long-enough" that would still eventually exceed the screen height, so
the scroll capability would still be needed.

RECOMMEND RE-OPENING
David: that sounds like a separate bug.  The original problem of the bookmarks
menu not scrolling has been fixed.
I also think it is better to open a new one for absence scrolling arrows in the
Filter Rules dialog. David, you are going? Or I can do it.
Good catch. But I can navigate to hidden folders by keyboard. With mouse - can't
reach them.
thank you, guys, for fixing this (long bm list) bug. Now, I can hide the
bookmarks tab in the sidebar. :-)
*** Bug 129516 has been marked as a duplicate of this bug. ***
*** Bug 130159 has been marked as a duplicate of this bug. ***
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.

Attachment

General

Creator:
Created:
Updated:
Size: