Closed Bug 13378 Opened 25 years ago Closed 25 years ago

[BETA] [DOGFOOD]Keyboard accelerators don't work

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: waterson)

References

Details

(Whiteboard: [PDT+]) 

Key shortcuts for menu item's seem to have broken on Mac recently. For example,
command-A for select all does not work.
That command-A example is in the editor, BTW
Err, well they do work, sometimes. Select All in the editor seems particularly
flaky, for some reason.
Ah, so it seems that I have to click on the menu before these shortcuts become
operational, for some reason. Weird.
It seems that using the control key, like control-A, *does* work first time.
Wait, you have to click on the menu in MacOS before things become operational?
Just bringing down the menu, or bringing down the menu and selecting the item
too?

I can't see how the menu could be related to keybinds in my code...
That's the effect I'm seeing, yes.
Just bringing down the menu, or bringing down the menu and selecting the item
too?

IE., does the JS have to get called for things to work?
First, the menu must have the open attribute set for things to work. This is the

menu interaction you are seeing, which means that it is in the menu list, which

means that the event can get fielded via the more standard MacOS shortcut key

event flow. I think that is what is executing, not the keybind at all according

to my tests.



Now, why the keybind is not executing is another question. A simple test in

navigator.xul shows all to be well. If I put in a keybind in EditorAppshell.xul

that is not defined via overlays, things work OK. I'll have to look at this more

tomorrow, but it looks like the problem is in the XUL, or, less likely, with

overlays.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M11
Ok, I think I have a fix for this, but I'm waiting on a verification from brade,
and akkana that I didn't hose up anything else. My tests look good, but I'm
paranoid.
Blocks: 13465
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Ok, fixed
Sorry for spam, re-assigning phillip's QA contact XPToolkit/XPWidget bugs to
claudius due to restructure
QA Contact: claudius → elig
QA Assigning to self for verification.
I just fixed keybinding again last night
Hey, Saari ---

There are a bunch of issues, although I'm not sure which are actually relevant,
as they're not exactly what Simon described in this Mac OS-only bug. (Can't find
dupes in Bugzilla, FWIW).

* Win32 1999111108: Select All doesn't do anything within Editor window, even
after placing focus. Opening Menu and pressing "Control-A" results in the menu
item being selected. (Doesn't work within Browser, either, but that's to be
expected with the menu item disabled. ;)

* Mac OS 1999111112: Keyboard accelerator for Select All *does* work within
editor

* Mac OS & Win32: File menu shortcut items like Open, Close, etc, frequently
don't do anything within browser or editor. But, they do sporadically work.

What say thee?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Re-opening to toss back onto saari's plate.
Blocks: 11818, 18033
Summary: Keyboard accelerators don't work → [DOGFOOD] Keyboard accelerators don't work
Keys aren't getting through at all on Linux as of 11/11 am (the ones hardwired
into the editor, like ^C, aren't working either).
Doh. From a quick 5 minute check, the behavior on Linux (1999111208) in Editor &
Browser looks identical to the behavior on Windows:
	- Editing keyboard accelerators don't work, other than within a text field
within the browser.
	- When the Edit menu is actually open, pressing an accelerator will select
the proper menu item within that menu.
	- File menu accelerators checked don't work within the editor, but do work
within the browser.
OS: Mac System 8.5 → Linux
Hardware: Macintosh → PC
OS: Linux → All
Hardware: PC → All
The problem seems to be related to the keylistener code looking for "oncommand"
but the editor keybinding is set up to observe a broadcaster which has the
"oncommand" attribute.

Changing platforms to All since I see this on Macintosh in Composer.
Blocks: 5716
Target Milestone: M11 → M12
Moving to M12...will release note for M11.
Whiteboard: [PDT-]
Putting on PDT- radar.  Not needed for dogfood, user can use mouse.
Have we changed what dogfood means? Dogfood is something that people are happy
enough with that they will use it day to day. Keyboard accelerators are important
enough for most people that I think this needs to be a PDT+ bug.
Whiteboard: [PDT-]
I agree with Simon.  Many people consider keyboard accelerators very important
to usability.  Please re-evaluate.  Besides, there are cases where the user
can't use the mouse, due to other bugs (e.g. cut/copy/paste not being hooked up
in the browser window).
Assignee: saari → waterson
Status: REOPENED → NEW
reassigning to waterson since he may have been the one to break them...
Status: NEW → ASSIGNED
looking...
Summary: [DOGFOOD] Keyboard accelerators don't work → [BETA] [DOGFOOD]Keyboard accelerators don't work
Whiteboard: [PDT-]
This bug has a workaround, though not the preferred result.  We need to know
which ones are working and which are not.  Eli, please do this.  rickg, etc felt
this is a lot of work which may not make it for dogfood, and is not absolutely
needed.

Putting on [BETA] radar.
What's the workaround for those of us who have other PDT bugs related to key
handling, if key events don't get through at all?  Or are you saying that all
the key event PDT bugs should now have their PDT+ designations removed from
them, because of this regression which broken a feature which was working just
fine a few days before the tree closed for M11?
Whiteboard: [PDT-] → [PDT+]
Putting on the PDT+ radar.
waterson, can you put a date to complete in the Status Summary please.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
This remains broken using this morning's builds:
	* Mac OS: Editor/Browser, other than Command-A within text fields or Editor
	* Win32: Editor/Browser, other than Command-A within text fields or Editor
	* Linux: Browser-only

Per waterson (thanks!), Akkana checked in a fix this morning which fix this
problem. Thus, deferring on re-opening until after evaluating a build with her
fix.
This remains broken using this morning's builds:
	* Mac OS: Editor/Browser, other than Command-A within text fields or Editor
	* Win32: Editor/Browser, other than Command-A within text fields or Editor
	* Linux: Browser-only

Per waterson (thanks!), Akkana checked in a fix this morning which fix this
problem. Thus, deferring on re-opening until after evaluating a build with her
fix.
Focus issues (and broken copy/paste/cut keyboard menu items aside) aside, using
the 1999112908 builds:

1. Mac OS
	- Editor: 	All shortcuts work.
 	- Browser: 	All shortcuts work except for "Preferences" (bug #20271), and
items under the "Go" menu (bug #20287)

[more platforms to come soon]
2. Windows NT 4.0 SP5
        - Editor:       Same as Mac OS.
        - Browser:      Same as Mac OS.

*** Note that within the Browser (all platforms), I didn't catch that Open Web
Location is busted. It's already in Bugzilla as bug #16280, on all platforms.
Sorry, got distracted writing up 20265.

*** Also, Edit Blank Page is busted within editor. Wrote bug #20298.
Status: RESOLVED → VERIFIED
Doh. I feel stupid. Edit Blank Page is busted by keyboard shortcut _both_ in
editor _and_ in browser. (Seamonkey also crashes upon closing a window by
keyboard shortcut, but saari says that a bug already exists for that.)

3. RH Linux 6.0/GNOME
        - Editor:       Same as Mac OS/Win32, except the Editing keyboard
shortcuts don't work (Copy/Cut/Paste/Select All). They do work within Browser
text fields.
        - Browser:      Same as Mac OS/Win32

Thus, I'm marking this bug as verified, and will open a separate bug for the
Editor keyboard shortcuts if one doesn't already exist.
Oops. This bug is just cursed. ;)

The actual Linux Editor problem is that keyboard shortcuts use the Control key
within the browser, but Alt key within the editor. I assume this is a known
issue, but e-mailed Akkana to be sure that a bug already exists for it.
[split final side-issue into 20348, "[PP] Linux - Some Keyboard Shortcuts use Alt
in Editor, Control in browser".]
No longer blocks: 13465
You need to log in before you can comment on or make changes to this bug.