Closed
Bug 13378
Opened 25 years ago
Closed 25 years ago
[BETA] [DOGFOOD]Keyboard accelerators don't work
Categories
(Core :: XUL, defect, P1)
Core
XUL
Tracking
()
VERIFIED
FIXED
M12
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.
Reporter | ||
Comment 1•25 years ago
|
||
That command-A example is in the editor, BTW
Reporter | ||
Comment 2•25 years ago
|
||
Err, well they do work, sometimes. Select All in the editor seems particularly
flaky, for some reason.
Reporter | ||
Comment 3•25 years ago
|
||
Ah, so it seems that I have to click on the menu before these shortcuts become
operational, for some reason. Weird.
Reporter | ||
Comment 4•25 years ago
|
||
It seems that using the control key, like control-A, *does* work first time.
Comment 5•25 years ago
|
||
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...
Reporter | ||
Comment 6•25 years ago
|
||
That's the effect I'm seeing, yes.
Comment 7•25 years ago
|
||
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?
Comment 8•25 years ago
|
||
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M11
Comment 9•25 years ago
|
||
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.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 10•25 years ago
|
||
Ok, fixed
Comment 11•25 years ago
|
||
Sorry for spam, re-assigning phillip's QA contact XPToolkit/XPWidget bugs to
claudius due to restructure
Updated•25 years ago
|
QA Contact: claudius → elig
Comment 12•25 years ago
|
||
QA Assigning to self for verification.
Comment 13•25 years ago
|
||
I just fixed keybinding again last night
Comment 14•25 years ago
|
||
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?
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 15•25 years ago
|
||
Re-opening to toss back onto saari's plate.
Updated•25 years ago
|
Comment 16•25 years ago
|
||
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).
Comment 17•25 years ago
|
||
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.
Updated•25 years ago
|
OS: Mac System 8.5 → Linux
Hardware: Macintosh → PC
Updated•25 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 18•25 years ago
|
||
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.
Comment 19•25 years ago
|
||
Moving to M12...will release note for M11.
Comment 20•25 years ago
|
||
Putting on PDT- radar. Not needed for dogfood, user can use mouse.
Reporter | ||
Comment 21•25 years ago
|
||
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.
Updated•25 years ago
|
Whiteboard: [PDT-]
Comment 22•25 years ago
|
||
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).
Updated•25 years ago
|
Assignee: saari → waterson
Status: REOPENED → NEW
Comment 23•25 years ago
|
||
reassigning to waterson since he may have been the one to break them...
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 24•25 years ago
|
||
looking...
Summary: [DOGFOOD] Keyboard accelerators don't work → [BETA] [DOGFOOD]Keyboard accelerators don't work
Whiteboard: [PDT-]
Comment 25•25 years ago
|
||
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.
Comment 26•25 years ago
|
||
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?
Comment 27•25 years ago
|
||
Putting on the PDT+ radar.
Comment 28•25 years ago
|
||
waterson, can you put a date to complete in the Status Summary please.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 29•25 years ago
|
||
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.
Comment 30•25 years ago
|
||
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.
Comment 31•25 years ago
|
||
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]
Comment 32•25 years ago
|
||
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.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 33•25 years ago
|
||
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.
Comment 34•25 years ago
|
||
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.
Comment 35•25 years ago
|
||
[split final side-issue into 20348, "[PP] Linux - Some Keyboard Shortcuts use Alt
in Editor, Control in browser".]
You need to log in
before you can comment on or make changes to this bug.
Description
•