Summary: | REGRESSION (r19313): All keyboard navigation has stopped working | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | David Kilzer (:ddkilzer) <ddkilzer> | ||||
Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | adele | ||||
Priority: | P1 | Keywords: | Regression | ||||
Version: | 420+ | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
Attachments: |
|
Description
David Kilzer (:ddkilzer)
2007-01-31 15:24:22 PST
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). Ack. I'm sure I caused this. Looking into this. 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. 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.
Comment on attachment 12837 [details]
patch
r=me
Committed revision 19319. |