Closed Bug 37988 Opened 25 years ago Closed 25 years ago

Menubar failures. Menus not drawing.

Categories

(Core :: XUL, defect, P3)

x86
Windows 2000
defect

Tracking

()

VERIFIED DUPLICATE of bug 28477

People

(Reporter: timeless, Assigned: mikepinkerton)

Details

Attachments

(1 file)

Make the window 242x167 Click Edit, menu paints correctly. Walk [arrows/mouse] to View, menu seems to paint correctly. Try to view the Toolbars or Character encoding submenus. walk to Search, then go. Walk to Bookmarks. Walk to Tas[ks] and points beyond. Eventually you wrap to File. Faulty behaviors: File menu doesn't paint No menus after go paint [Bookmarks, Tasks, ...] The submenus of view don't paint. Expected behaviors: File Bookmarks and Tasks menus should paint. View submenus should paint. I don't object to the fact that things after tasks don't paint. Perhaps the IE approach of having excess menus drop down should be considered? [In which case, Tasks would be replaced by a down widget containing tasks...qa]
Testing this on WinNT with the 2000-05-02-08-M16 and 2000-05-02-15-M16 nightly binaries, there does seem to be a bug here, but it does not appear to have anything to do with the size of the window. Making the Mozilla window as small as possible -- roughly 80px wide by 20px tall -- so that, aside from the titlebar, only the whitespace above the File, Edit, and View menu names is visible, it is possible to walk all menus and all submenus using the arrow keys after giving focus to one of the menus by clicking on its name (or rather, the visible part of its hotspot), *so long as* the mouse pointer is moved off of the menubar before using the arrow keys. It is even possible to walk menu items and submenus by mousing on the menus that can only be reached by keyboarding because their names are clipped by the small size of the Mozilla window. On the other hand, no matter what size the Mozilla window is, if a menu is given focus by clicking on its name and the pointer is left over the menubar, using the left and right -arrowkeys does not work properly: the menu name to the left or right is momentarily highlighted, but that menu never appears and the original menu reappears. Sometimes the adjacent menu does display, but the one after snaps back to the original menu where the pointer is still parked. This is something of an edge case -- most people who begin to use a menu by mousing will have moved the pointer into that menu before changing their minds and trying to access another menu -- but still a bug. I'm guessing that it may also be a DUP. If a menu is given focus by (for example) ALT+F, walking the menu by keyboarding always works no matter what the Mozilla Window size is.
Summary: Menubar failures. Menus noxt drawing. → Menubar failures. Menus not drawing.
i don't see the original problem, but i know about the jumping when mouse & keyboard are both used. *** This bug has been marked as a duplicate of 28477 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
vrfy
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: