Bug 12516 – REGRESSION (r19313): All keyboard navigation has stopped working

• Component: Accessibility
• Status: RESOLVED FIXED

[David Kilzer (:ddkilzer)]

All keyboard navigation appears to have stopped working.  For example:

- Using arrow keys to scroll up/down and left/right on the page.
- Using Cmd-Left to go back in history, or Cmd-Right to go forward in history.

I'm pretty sure this is a regression from r19313.

[David Kilzer (:ddkilzer)]

Summary:

Keyboard navigation in Safari/WebKit has stopped working.

Steps to reproduce:

1. Open Safari/WebKit.
2. Open a page that scrolls vertically and horizontally.
3. Use arrow keys to scroll page vertically and horizontally after it has loaded.

Expected results:

Arrow keys will scroll page in the appropriate direction.

Actual results:

Arrow keys do nothing; it appears that keyboard events at the browser level are completely ignored.

Regression:

Tested with a locally-built debug build of WebKit r19315 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037).

This is a regression from shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037).

[Adele Peterson]

Ack. I'm sure I caused this. Looking into this.

[David Kilzer (:ddkilzer)]

Confirmed regression occurred in r19313.

[Adele Peterson]

I have a fix for this.

I moved the check for _canEdit into WebCore (Editor::insertText), and of course, this means that check is never run for other commands.

[Adele Peterson]

Created attachment 12837 [details]
patch

Note- In my last change, I added this isContentEditable check to insertText.  This patch doesn't take that check out.  In the future, I want to make execCommand call Editor::insertText, so that check will still be useful.

[Adam Roben (:aroben)]

Comment on attachment 12837 [details]
patch

r=me

[Adele Peterson]

Committed revision 19319.