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)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sidr, Assigned: bugzilla)

References

Details

(4 keywords)

Attachments

(3 files)

patch - let spacebar through. should we restrict this to win-only?
(deleted), patch
Details | Diff | Splinter Review
[patch] not good either?
(deleted), patch
Details | Diff | Splinter Review
[patch] (app needs to be able to handle ctrl+alt+space, but not shift+alt+space)
(deleted), patch
Details | Diff | Splinter Review 
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: polish → access, 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 ago → 24 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: