Backspace key in form fields in desktop Linux Fennec goes back a page instead of deleting

RESOLVED FIXED in Firefox 10


8 years ago
8 years ago


(Reporter: mbrubeck, Assigned: romaxa)



Firefox 9
Firefox 10
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)

Since bug 682017 landed, pressing backspace in an <input> field in web content in desktop Fennec does not delete characters.  Instead, it navigates back a page.

Android is not affected by this bug (possibly because the backspace shortcut is disabled on Android, bug 635495).
Sounds like we should handle properly prevent default case in better way
Assignee: mbrubeck → romaxa
Based on some logging, pressing backspace sends keydown and keyup events in the content process, but no keypress event...
(In reply to Matt Brubeck (:mbrubeck) from comment #2)
> Based on some logging, pressing backspace sends keydown and keyup events in
> the content process, but no keypress event...

Nevermind, this is not true.  It was an error in my debugging.
Afaict, this code should be called:
where on line 5021, the backspace key event is consumed.
First of all we should do rpc calls in SendRealKeyEvent... and return nsEventStatus back to UI.
Secodn problem I found that event with handling remote browser event status we still have mainKeySet handling event before remote browser.

ContentCustomKeySender.prototype: handleEvent:keypress - Fennec UI container get's event
nsXBLWindowKeyHandler::WalkHandlers(nsIDOMKeyEvent*, nsIAtom*)::326  prevent:0
nsXBLWindowKeyHandler::WalkHandlers(nsIDOMKeyEvent*, nsIAtom*)::326  prevent:0
CallRealKeyEvent::316 Before call child process status:0
nsXBLWindowKeyHandler::WalkHandlers(nsIDOMKeyEvent*, nsIAtom*)::326  prevent:1  XBLkeyhandler get's 3 keypress events before remote browser handle it.
AnswerRealKeyEvent::635 status:1
Content key press received: prevent:true
SendRealKeyEvent::317 status:1

Is it possible to make UI mainKeySet handle event after remote browser frame?
Attachment #557384 - Flags: review?(mbrubeck)
idea is very simple, allow content dispatch events as it is, but with disabled keyset, and when content bubble not used event back, enable keyset and handle that event
Comment on attachment 557384 [details] [diff] [review]
Disable keyset until respond from content received.

Kind of hacky, but at least it's less hacky than my old code that bug 682017 removed. :)

This patch disables the keyset for every keypress event that gets forwarded, but it re-enables it only when it gets a message from the content process.  The content process does not send a message for events with getPreventDefault(), so there are cases where the keyset isn't re-enabled after the keypress.

We could fix this by sending a message for every keypress event, but redispatch the event in the parent process only if the message has preventDefault set to false.
Attachment #557384 - Flags: review?(mbrubeck) → review-
Attachment #557384 - Attachment is obsolete: true
Attachment #557597 - Flags: review?(mbrubeck)
Comment on attachment 557597 [details] [diff] [review]
Disable keyset until respond from content received.

>       case "Browser:KeyPress":
>+        var keyset = document.getElementById("mainKeyset");

Use "let" and add braces around the whole case block.

>+        if (json.preventDefault) {
>+          break;
>+        }

No braces.

r=mbrubeck.  I can fix the nits and check this in.
Attachment #557597 - Flags: review?(mbrubeck) → review+
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → Firefox 9
Depends on: 684558
backed out.  caused 684558.
Resolution: FIXED → ---
Try run is green:

Pushed to inbound:
Target Milestone: Firefox 9 → Firefox 10
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Depends on: 691418
You need to log in before you can comment on or make changes to this bug.