Closed Bug 14464 Opened 21 years ago Closed 21 years ago

[BLOCKER] XUL key bindings not firing

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: saari)

References

Details

(Whiteboard: Closing in... steady... steady...)

On Linux, control and alt key events don't get handled by the editor's key
handler.  This is true both of bindings which XUL should handle, and bindings
which the editor key events should handle.
Akkana--can you clarify what you mean by control and alt keys (like give me an
example for each)?  Do you see this in the browser, editor or both?

There are some keybinding issues on Mac in today's build as well.  I notice that
in the browser window, Command-Q doesn't quit until I click in the menu first.
However, in Composer, I can't quit at all with Command-Q.
Assignee: akkana → saari
OS: Linux → All
Priority: P3 → P2
Hardware: PC → All
Summary: [PP] Editor not handling control and alt key events → XUL not firing
Target Milestone: M11
For instance, control-B doesn't do anything -- it doesn't trigger the XUL JS
comment to make bold.

It turns out that XUL isn't firing on any platform.  On Windows, ^B does make
bold, but not via XUL -- it goes straight to the editor key listeners file,
which is tuned to work on Windows but perhaps not on other platforms.

It may be that someone else is intercepting that ^B before it gets to XUL (which
would also explain why the hardwired editor key bindings aren't doing it, but
which does not explain why it would be working on Windows).
Summary: XUL not firing → [BLOCKER] XUL not firing
Blocks: 13873
Status: NEW → RESOLVED
Closed: 21 years ago
Priority: P2 → P1
Resolution: --- → FIXED
Fixed by adding code from nsRDFElement::HandleDOMEvent() to do capturing in
nsGenericElement::HandleDOMEvent(). Verified by Hyatt.
Status: RESOLVED → REOPENED
This fixes XUL when the focus is in the browser urlbar or chrome, but not when
the focus is in the browser or editor content areas.  Bummer.
Summary: [BLOCKER] XUL not firing → [BLOCKER] XUL key bindings not firing
Hyatt has a fix for this too, about to checkin
Resolution: FIXED → ---
Fixed in a broader sense this time, in both nsGenericElement::HandleDOMEvent *

and* nsRDFElement::HandleDOMEvent()



Tested in editor
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
marking fixed again, since I think it is
No longer blocks: 13873
Status: RESOLVED → REOPENED
hmmm... not working on my build on Mac from this morning around 7:45am PDT...
reopening
Resolution: FIXED → ---
Not working on Linux either.
*** Bug 14761 has been marked as a duplicate of this bug. ***
mass migration to m10
Whiteboard: Closing in... steady... steady...
Okay... I checked in a new version of nsXULKeyListener with a bunch of changes that should help all platforms. nsMacEventHanlder also got tweaked a little, and akkana is going to check in the GTK event handler change.

To make it more complicated, Paul Hangas is going to check in some XUL overhauls that also affect keys...?
I've checked in changes to the gtk event handler to track saari's changes and
the fact that joki's backend code currently expects ascii control char values
for control key events (e.g. 1 instead of 'a' for the char code for control-a).
This should fix XUL handling on Unix for M10, and we'll all revisit key handling
for M11.
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
marking fixed.  we should open another for key handling in m11 if thats needed.
Turns out that bug 13908 prevents keybinding from being usable.
This may be considered an M10 blocker still, so I'm making 13908 an M10 bug and
assigning to waterson.
Blocks: 15156
Status: RESOLVED → VERIFIED
verified
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.