BuildID: 2000043015 See picture. I think that submenus for menu item 0 of a menu draws one pixel lower than other submenus. There are also other rules like the bottom edge of the top item [when selected] on a submenu [not 0] is a pixel lower than the selected parent. Reproducible: Always Steps to Reproduce: click bookmarks, mouse over various menu items w/ children [0th items behave differently from other items -- as parents] Actual Results: Cascading a single pixel down Expected Results: no drop as menus cascade. Each line of text should have the same baseline as it's parent and child.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → M20
Is this specific to Windows or is it xp?
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
Dean: I think this is XP. German: do we like this 'feature'? Hyatt: could we fix this?
I think this has long since been fixed. The screenshot is of the blue skin, which is obsolete.
This still happens in modern2 and classic [9/26-8], but this windows nt box doesn't have paint [or any app that can save images]...
Created attachment 15598 [details] Screenshot attached. Anyone know the function, off the top of their head, that positions submenus?
Dean, the routine that positions everything is in http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsMenuPopupFrame.cpp#477 in SyncViewWithFrame(). Patches would be welcome. I will go on record saying that I'm never going to waste my time to fix this ;)
Severity: normal → trivial
Updating summary. w/ newer skins it becomes very clear I want text tops to line up. Thank you pinkerton, only 292 lines, this should be pretty easy :-)
Keywords: mozilla0.9, ui
Summary: The bookmarks menu is drawing badly Either submenus should have the same text top as their parent's item or the same Menu Item top → The bookmarks menu is drawing badly. Submenus should have the same text top as their parent's item
Suggested Fix: if the submenu is opened by the first frame in its parent, align the submenu with the top of the popup frame instead of the menu frame.
Dean: the problem is now consistent, it doesn't matter if the parent is item 0, 1 or 20. Is it possible to ask the popup window to orient based on a child instead of its top left corner. Hrm What if.. the popup menu is created (somewhere), we ask its first child for it's top coord, and use that to get a delta (relative to the popup menu top). In reality, this delta should not change unless the skin is changed. Then we can just subtract this from the popup whenever we create it. On skin change this is discarded, and regenerated.
Whiteboard: 4xp → [insight in bug, c++ parsing needed]
Or just try and align the top of the text of the first menu frame within the popup menu with the given co-ordinates, instead of aligning the popup frame.
*** Bug 29069 has been marked as a duplicate of this bug. ***
There's another good screenshot in bug 29069.
*** Bug 74580 has been marked as a duplicate of this bug. ***
*** Bug 97077 has been marked as a duplicate of this bug. ***
Summary: The bookmarks menu is drawing badly. Submenus should have the same text top as their parent's item → The bookmarks menu is drawing badly. Submenus should align text top with their parent's item
Confirming in latest trunk nightlies! BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614 Firefox/1.0+ ID:2005061405 Here is a current screenshot from the above build: http://img21.echo.cx/my.php?image=unalignedmenus3cl.jpg Bookmark dropdown menus also exhibit this bug. A fix for this would improve the look and feel of FF greatly in terms of OS integration.
If I remember correctly this issue can be fixed by the patch in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=253661
yes bug 253661 does address some of the issues
Assignee: mikepinkerton → nobody
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.menus
Whiteboard: [insight in bug, c++ parsing needed]
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.