Closed Bug 75142 Opened 24 years ago Closed 23 years ago

when opening a bookmarks menu that needs scroll arrows, ALL parent menus get scroll arrows

Categories

(Core :: XUL, defect)

x86
Windows 98
defect
Not set
minor

Tracking

()

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: b_ironfist, Assigned: mikepinkerton)

References

Details

(Whiteboard: [br])

Attachments

(2 files)

moz build: 2001040604 when I browse bookmarks to a folder that requires scroll buttons to view it comepletely, all my bookmark folders get scroll buttons they continue to have scroll buttons (whether they need them or not) throughout the mozilla session upon restarting mozilla the extranious scroll buttons are gone (until I browse to a folder in my bookmarks that needs scroll buttons that is) scroll buttons apprear 100% of the time I fold out a large bookmark folder the buttons should be appearing on ONLY the folders that need them, not everything
steps to (re)produce bug 1: click on "bookmarks" 2. browse to a folder listing that is too large for screen display 3. sit back and watch as mozilla adds scroll buttons to all your bookmark folders
upon further investigation, I noticed that it is not ALL bookmark folders that get the scroll buttons, just the one that is supposed to get it, and all it's parents - ie. all OPEN bookmark folders get scrollbuttons (which don't go away until restarting mozilla)
Also seeing this Windows 2000, build 2001040420. This doesn't happen on build 2001040120
a temporary workaround for this problem. patch against mozilla/content/xul/content/src/nsXULElement.cpp. --- nsXULElement.cpp.org Tue Apr 10 09:05:49 2001 +++ nsXULElement.cpp Tue Apr 10 09:09:20 2001 @@ -3682,6 +3682,7 @@ //Bubbling stage if (NS_EVENT_FLAG_CAPTURE != aFlags) { + if(parent.get() != mParent) parent = mParent; if (parent != nsnull) { // We have a parent. Let them field the event. ret = parent->HandleDOMEvent(aPresContext, aEvent, aDOMEvent,
Marking NEW to get someone to take a look at the patch.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: patch, review
*** Bug 83224 has been marked as a duplicate of this bug. ***
changing component and tweaking summary
Summary: when openening a bookmarks folder that needs scroll buttons, ALL folders get scroll buttons → when opening a bookmarks menu that needs scroll arrows, ALL parent menus get scroll arrows
for real this time
Assignee: ben → pinkerton
Component: Bookmarks → XP Toolkit/Widgets: Menus
QA Contact: claudius → jrgm
->0.9.3
Target Milestone: --- → mozilla0.9.3
This also affects Linux builds (including build 2001060508)
*** Bug 76063 has been marked as a duplicate of this bug. ***
Screenshots I had put into bug 76063... attachment 34915 [details] - bookmarks menu attachment 34916 [details] - Imported IE Favorites submenu attachment 34917 [details] - Auto-scrolling submenu is created, and all three menus are now auto-scroll.
This patch doesn't sit well with me. "if(parent.get() != mParent) parent = mParent" is a long way of saying "parent = mParent", which doesn't seem right.
Dean wrote in Bug 76063: > Definitely. I knew there was another one in here, I just couldn't find it. Hey Dean, do you take my bug 76828 as a dupe of this bug? (I thought I've got *the* another one...) :)
*** Bug 86965 has been marked as a duplicate of this bug. ***
*** Bug 91525 has been marked as a duplicate of this bug. ***
Isn't this the same as bug 84121?
No it's not. Compare the screenshots that I listed in this bug on 2001-06-11 10:03 to a screenshot from 84121 (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37665) It may end up that the two bugs are related, but they need to be kept separate.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Who originally did the scrolling menu work, evaughan?
yes, and he's, well, not doing much these days.
Status: NEW → ASSIGNED
cc:ing Jan, who's done some work with scrolling menus before.
*** Bug 93633 has been marked as a duplicate of this bug. ***
Attached patch proposed fix (deleted) — Splinter Review
I took look and got a patch. Patch is not well tested but it fixes described problem.
this kinda makes sense to me. kinda. pink, wanna have a looksee in evaughan's absence?
Whiteboard: [br]
I'm running with the patch right now. It resolves the problem and everything else, such as menulists, _appears_ to be working properly.
yeah, i like this. sr=hyatt r=pink also
thanks, I'll check it in when tree opens
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 94283 has been marked as a duplicate of this bug. ***
verified on 2001080804. thanks Jan!
Status: RESOLVED → VERIFIED
As of build 2001080804 - WinMe This does indeed fix the multi-arrow problem thanks. However, as it fixes some of the problem with the menu scroll bars being below the screen it does not fix every instance. (Not sure if this was intended to do this as well, or just a nice side effect) I will attach a screen shot.
Christoph: that's bug 84121
*** Bug 94591 has been marked as a duplicate of this bug. ***
*** Bug 95177 has been marked as a duplicate of this bug. ***
*** Bug 95950 has been marked as a duplicate of this bug. ***
*** Bug 97635 has been marked as a duplicate of this bug. ***
The "persistent" scroll arrows appear also in another context. When opening bookmarks menu, which has it's height equal to the maximized Mozilla window, with Mozilla window not at the top of the workspace (i.e. not minimized) this menu gets scroll arrows. Thats good. But when one maximize Mozilla window they do not vanish. The bookmarks menu *with scroll arrows* has its height larger than screen height. The scroll arrows necessary only because there are scroll arrows. They have to scroll only one row of bookmarks.
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

Created:
Updated:
Size: