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)
Core
XUL
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)
883 bytes,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
3.61 KB,
patch
|
hyatt
:
review+
roc
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
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
Comment 2•22 years ago
|
||
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.
Comment 5•22 years ago
|
||
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.
Comment 8•22 years ago
|
||
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
Comment 9•22 years ago
|
||
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.
Comment 10•22 years ago
|
||
*** Bug 124542 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
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
Comment 12•22 years ago
|
||
roc: have there been any view manager changes recently that could have caused this?
Ah, yes there have :-)
Comment 14•22 years ago
|
||
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...
Comment 16•22 years ago
|
||
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.
Assignee | ||
Comment 18•22 years ago
|
||
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
Really? That should never happen.
Assignee | ||
Comment 21•22 years ago
|
||
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=
Comment 22•22 years ago
|
||
restoring accidentally removed +
Comment 23•22 years ago
|
||
Comment on attachment 70399 [details] [diff] [review] Patch Rev 1 r=kmcclusk@netscape.com
Attachment #70399 -
Flags: review+
Comment 24•22 years ago
|
||
*** Bug 126514 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 25•22 years ago
|
||
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 :-).
Comment on attachment 70399 [details] [diff] [review] Patch Rev 1 sr=roc+moz
Attachment #70399 -
Flags: superreview+
Comment 30•22 years ago
|
||
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
Comment 31•22 years ago
|
||
*** Bug 126595 has been marked as a duplicate of this bug. ***
kin, check this sucker in. preemptive a=roc+moz for 0.9.9
Assignee | ||
Comment 33•22 years ago
|
||
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. :-)
Comment 34•22 years ago
|
||
*** Bug 126682 has been marked as a duplicate of this bug. ***
Comment 35•22 years ago
|
||
*** Bug 126830 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 36•22 years ago
|
||
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
Comment 37•22 years ago
|
||
*** Bug 126871 has been marked as a duplicate of this bug. ***
Comment 38•22 years ago
|
||
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.
Assignee | ||
Comment 39•22 years ago
|
||
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.
Comment 40•22 years ago
|
||
> 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
Assignee | ||
Comment 41•22 years ago
|
||
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 → ---
I know next to nothing about menus. You need to talk to pinkerton.
Assignee | ||
Comment 43•22 years ago
|
||
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.
Comment 45•22 years ago
|
||
*** Bug 127149 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 46•22 years ago
|
||
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.
Comment 47•22 years ago
|
||
*** Bug 127308 has been marked as a duplicate of this bug. ***
Comment 48•22 years ago
|
||
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.
Comment 50•22 years ago
|
||
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.
Comment 51•22 years ago
|
||
*** Bug 127487 has been marked as a duplicate of this bug. ***
Comment 52•22 years ago
|
||
*** Bug 127501 has been marked as a duplicate of this bug. ***
Comment 53•22 years ago
|
||
Want this fixed in 0.9.9 if possible, else 1.0 for sure. /be
Blocks: 122050
Comment 54•22 years ago
|
||
*** Bug 127556 has been marked as a duplicate of this bug. ***
Comment 55•22 years ago
|
||
*** Bug 127613 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 56•22 years ago
|
||
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.
Comment 57•22 years ago
|
||
*** Bug 127834 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
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+
Comment 59•22 years ago
|
||
*** Bug 127992 has been marked as a duplicate of this bug. ***
Comment 60•22 years ago
|
||
*** Bug 128047 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 61•22 years ago
|
||
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().
Comment 62•22 years ago
|
||
*** Bug 128123 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 63•22 years ago
|
||
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]
Comment 64•22 years ago
|
||
kin: in case Hyatt didn't mention the bug for that, it's bug 78344.
Comment 65•22 years ago
|
||
*** Bug 128485 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 66•22 years ago
|
||
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
Comment on attachment 72150 [details] [diff] [review] Patch Rev 3 sr=roc+moz
Attachment #72150 -
Flags: superreview+
kin, can you get a review of this from hyatt or pinkerton? We'd like this to make 0.9.9.
Comment 69•22 years ago
|
||
*** Bug 128769 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 70•22 years ago
|
||
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=
Comment 71•22 years ago
|
||
*** Bug 128932 has been marked as a duplicate of this bug. ***
Comment 72•22 years ago
|
||
*** Bug 121871 has been marked as a duplicate of this bug. ***
Comment 73•22 years ago
|
||
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 74•22 years ago
|
||
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+
Assignee | ||
Comment 75•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → FIXED
Whiteboard: [driver:dbaron] FIX IN HAND, need a= → [driver:dbaron]
Comment 76•22 years ago
|
||
Fixed on Win2K using 2002030604 How about Mac and Linux?
Comment 77•22 years ago
|
||
Fixed on Linux 2002030521 trunk.
Reporter | ||
Comment 78•22 years ago
|
||
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
Comment 79•22 years ago
|
||
Even fixed in OS/2 2002030616
Comment 80•22 years ago
|
||
Fixed in Mac OS 9 (checked font dropdown in Preferences) Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.9+) Gecko/20020306
Comment 81•22 years ago
|
||
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
Comment 82•22 years ago
|
||
David: that sounds like a separate bug. The original problem of the bookmarks menu not scrolling has been fixed.
Reporter | ||
Comment 83•22 years ago
|
||
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.
Comment 84•22 years ago
|
||
thank you, guys, for fixing this (long bm list) bug. Now, I can hide the bookmarks tab in the sidebar. :-)
Comment 85•22 years ago
|
||
*** Bug 129516 has been marked as a duplicate of this bug. ***
Comment 86•22 years ago
|
||
Done: http://bugzilla.mozilla.org/show_bug.cgi?id=129572
Comment 87•22 years ago
|
||
*** 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.
Description
•