Closed Bug 19328 Opened 25 years ago Closed 24 years ago

[Windows] ALT+SPACEBAR is not activating control menu

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sidr, Assigned: bugzilla)

References

Details

(4 keywords)

Attachments

(3 files)

Overview: For any windows progam, typing ALT+SPACEBAR (press ALT, hit spacebar, release ALT) should activate the control menu - the one that is otherwise accessed by clicking on the application icon at the very left end of the title bar. Mozilla isn't doing this. This means that any Mozilla window cannot be minimized, maximized, moved, or re-sized without using the mouse. Steps to Reproduce: 1. Launch any Mozilla App. 2. Type ALT+SPACEBAR (press ALT, hit spacebar, release ALT) Actual Result: Nothing at all. Expected Result: The control menu activates so that a selection can be made from it. Tested with: 1999-11-17-17-M12 nightly binary on Windows NT. This almost certainly occurs on all Windows OS.
Assignee: joki → saari
Component: Event Handling → XPMenus
QA Contact: janc → sairuh
Summary: [Windows] ALT+SPACEBAR is not activating control menu → [Windows] ALT,SPACEBAR is not activating control menu
ALT+SPACEBAR is now properly activating the Win32 control menu on NT and 98 at least. But, ALT,SPACEBAR is also a valid way to activate the control menu (press ALT, release (focus now on menubar), press SPACEBAR), and that is not working. Works partially-correctly on: 1999-12-15-08-M12 nightly binary on Windows NT 4.0sp3 1999-12-14-08-M12 nightly binary on Windows 98 SE 1999-11-25-08-M12 nightly binary on Windows 98 (according to bug 20108) Changing Summary from "[Windows] ALT+SPACEBAR is not activating control menu" to "[Windows] ALT,SPACEBAR is not activating control menu" to match current behavior. Changing Component to "XPMenus" from "Event Handling"; changing QA Contact to match.
Priority: P3 → P5
Target Milestone: M20
Please, do not morph bugs like this. If the alt+spacebar regresses, we no longer have a bug in place to test for it and reopen. Instead of morphing bugs, please open new ones. assigning to saari as p5 for m20
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Summary: [Windows] ALT,SPACEBAR is not activating control menu → [Windows] ALT+SPACEBAR is not activating control menu
Returning this bug to its original summary and intent, marking WORKSFORME. Retested with 2000-01-06-08-M13 nightly binary on Windows NT 4.0sp3 Bug 23445, "[Windows] ALT,SPACEBAR is not activating control menu" has been opened for that specific case. Adding notation to bug 13372, "[PP] Win32 - Alt-Space scrolls down but shouldn't", REOPENED, referring to this bug.
This one kind of 'worksforme' now - but on my 2000010908 build (WinNT4 SP6) you need to click on the document window before pressing alt-space in order to make the menu appear. If I try pressing alt-space right after entering a URL, nothing happens - the cursor just keeps blinking in the URL field.
verified WFM, using 2000-01-11-08 comm. bits on winNT. Antti.Nayha@oulu.fi, to respond to your last comment, there is a known problem where you need to first click inside the mozilla window in order for keyboard tasks to be recognized. i believe this is described in bug 9701.
Status: RESOLVED → VERIFIED
OK, there are still a few problems with Alt-Space - but those seem to be bugs 9701 and 13372. Marking this one Verified/Worksforme.
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
Restested with the 2000-02-24-08-M14 nightly binary on WinNT I could get the control menu to show by keying ALT+space+space or ALT-release,ALT+space, but not by keying ALT+space. REOPENing. ALT,space -- the subject of bug 23445, did not work either. These problems are quite possibly a result of either the regression in bug 18598, "menus take focus on "alt," then behave in a non-standard way", (2000-02-14) or its fix.
Status: VERIFIED → REOPENED
Keywords: 4xp, regression
Resolution: WORKSFORME → ---
Hyatt gets this
Assignee: saari → hyatt
Status: REOPENED → NEW
Status: NEW → ASSIGNED
*** Bug 23445 has been marked as a duplicate of this bug. ***
Mass move of all M20 bugs to M30.
Mass move of M20 bugs to M30
Target Milestone: M20 → M30
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.
QA Contact: sairuh → jrgm
*** Bug 41407 has been marked as a duplicate of this bug. ***
*** Bug 23445 has been marked as a duplicate of this bug. ***
*** Bug 23445 has been marked as a duplicate of this bug. ***
At one point this bug was fixed except for the case covered by bug 23445, so I morphed it, but Peter Trudelle cautioned against that in case there was a regression, so I opened bug 23445 and changed this bug back to its original meaning... and then it did regress. So there are two distinct codepaths for the differing key event sets; conceivably this could end up fixed again by work on another bug related to ALT+ without fixing the ALT,SPACEBAR problem; in that case, it would be best to reopen 23445. FWIW, I disagree with a 'Future' milestone... Netscape 6 will get compared to IE5 on IE5's home turf by reviewers, and this is exactly the kind of detail that a writer could hang a sour-note-with-sustain on. ALT+SPACE and ALT,SPACE trigger, from the user's point of view, Windows desktop actions, not application actions; the user expects to leave whatever app has desktop focus when either keycombo is used, and an app that won't will appear to be partially broken. Changes to functionality affecting them are not in the same class as changes resulting form the use of XP widgets, as they are meant to be externally-, not internally- consistent. Adding "polish" keyboard because I think it's warranted. Changing to new "Keyboard Navigation" component. One other note: there is no point talking about workarounds for variant keycombos, mentioned above and in bug 23445, as ALT+SPACE, for those that use it, is as much an atomic action as CTRL+S...
Component: XP Toolkit/Widgets: Menus → Keyboard Navigation
Keywords: polish
QA Contact: jrgm → szhu
*spam* changing all open or resolved bugs that szhu@netscape.com was the QA contact for to sairuh@netscape.com. szhu is no longer with netscape, and these bugs could lie dormant otherwise. sorry for spam.
QA Contact: szhu → sairuh
*** Bug 48088 has been marked as a duplicate of this bug. ***
*** Bug 48019 has been marked as a duplicate of this bug. ***
*** Bug 49267 has been marked as a duplicate of this bug. ***
Is this bug _that_ difficult a fix? Considering bug 20847 looks like something that we're not going to see fixed before release, being forced to then use the mouse to maximise each window after Ctrl-N'ing for a new window seems to only rub salt in the wound. There can't be that much involved in hooking this up is there? I'd have thought a few minutes for someone who knew their way around the code... Monitor for an ALT+Space press, when there is one, fire off the appropriate message to Windows and let it pop up the menu...
This isn't working in the October 19, 2000 builds. Are we seriously going to ship without a fix for this?
IMO, I think this is VERY important to fix for RTM for people who don't have mice or anything but a keyboard installed unless there is another way of getting to the control menu to do such things as resize, move, maximize or minimize. After installing a fresh install of Windows 95 on an old computer with no mouse, I installed Mozilla. The default position of Mozilla was half-way off the screen. After many minutes of frustration trying to get to the control menu with keyboard shortucts so that I could move or resize my window, I gave up and installed IE. Besides getting a mouse, is there another workaround?
As noted by Peter Lubczynski, there do not appear to be any keyboard-only workarounds for activating the MS-Win control menu. Specifically, neither ALT+Space+Space, nor ALT-release, ALT+Space, which at one point activated this functionality, and would presumably be found by a user that kept trying, do anything anymore. Tested using PR3 and 2000-10-20-09-Mtrunk on WinNT 4.0. Adding "access" and "correctness" keywords.
Keywords: polishaccess, correctness
*** Bug 57918 has been marked as a duplicate of this bug. ***
taking this
Assignee: hyatt → blakeross
Status: ASSIGNED → NEW
You can't let ALT through here. This patch will cause other problems.
*** Bug 58708 has been marked as a duplicate of this bug. ***
Ah...I figured. I think I have a better idea, though. Out of curiousity, what consequences of this patch do you foresee?
Status: NEW → ASSIGNED
adding rtm keyword. This bug should not be ignored.
Keywords: rtm
uhh. this isn't rtm material.
Keywords: rtm
Priority: P5 → P3
Target Milestone: Future → mozilla1.0
*** Bug 60624 has been marked as a duplicate of this bug. ***
*** Bug 60950 has been marked as a duplicate of this bug. ***
bigger things to worry about right now. back to hyatt.
Assignee: blakeross → hyatt
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → ---
Attached patch [patch] not good either? (deleted) — Splinter Review
Hyatt, what about handling shortcircuiting this early (when WM_CHAR is fired)? Will this cause problems also?
See analysis of similar patch in bug 57019. r=danm.
sr=alecf
Thanks. hmm...I didn't even know about that bug. The patch over there is smaller and neater...
Assignee: hyatt → blakeross
Fix checked in.
Status: NEW → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
works fine. vrfy on winnt using 2000.12.21.09 comm verif bits.
Status: RESOLVED → VERIFIED
Keywords: pp
*** Bug 64123 has been marked as a duplicate of this bug. ***
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: