Currently there’s code in the guts of the event-handling mechanism that causes the Backspace/Delete key to do a Go Back navigation (also Go Forward with a modifier-key variation) if it’s not intercepted by a form control. This setting should be configurable so that a client can choose to suppress it.
Created attachment 112912 [details] Patch to add a WebCore setting and corresponding WebKit/WebKit2 preferences, with no change to current behavior
We often try to add tests to TestWebKitAPI for changes like this these days.
I’ll look into adding a TestWebKitAPI test separately. No promises though!
Ah, I realize that I need to honor this new preference in WebFrameView in WebKit (as well as in the event-handling code in WebCore; not sure if the WebFrameView one still needs to exist, but since it does exist, it should honor this preference). Tweaked patch forthcoming.
Created attachment 112918 [details] Same as last patch except also honors preference in WebFrameView.mm in WebKit
Fixed in http://trac.webkit.org/changeset/98769
Comment on attachment 112912 [details] Patch to add a WebCore setting and corresponding WebKit/WebKit2 preferences, with no change to current behavior View in context: https://bugs.webkit.org/attachment.cgi?id=112912&action=review > Source/WebCore/page/EventHandler.cpp:3028 > + if (!m_frame->settings()->backspaceKeyNavigationEnabled()) > + return; Since the settings object actually hangs off the page, not the frame, this needs to be done after checking the page is null.
I see. I’ve checked it in, so I’ll fix that in a separate patch.
Reopening for change Darin mentioned.
Created attachment 112949 [details] Move the frame->settings() test to after the !page test.
Checked in this additional change in 98788.