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

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Matt Brubeck (:mbrubeck)]

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).

Comment 1

[Oleg Romashin (:romaxa)]

Sounds like we should handle properly prevent default case in better way

Comment 2

[Matt Brubeck (:mbrubeck)]

Based on some logging, pressing backspace sends keydown and keyup events in the content process, but no keypress event...

Comment 3

[Matt Brubeck (:mbrubeck)]

(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.

Comment 4

[Martijn Wargers (dead)]

Afaict, this code should be called:
http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/base/nsEditor.cpp#5015
where on line 5021, the backspace key event is consumed.

Comment 5

[Oleg Romashin (:romaxa)]

First of all we should do rpc calls in SendRealKeyEvent... and return nsEventStatus back to UI.

Comment 6

[Oleg Romashin (:romaxa)]

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?

Comment 7

[Oleg Romashin (:romaxa)]

Attachment: Disable keyset until respond from content received.

Comment 8

[Oleg Romashin (:romaxa)]

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 9

[Matt Brubeck (:mbrubeck)]

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.

Comment 10

[Oleg Romashin (:romaxa)]

Attachment: Disable keyset until respond from content received.

Comment 11

[Matt Brubeck (: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.

Comment 12

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d4c725db7369

Comment 13

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/d4c725db7369

Comment 14

[Doug Turner (:dougt)]

backed out.  caused 684558.

Comment 15

[Matt Brubeck (:mbrubeck)]

Try run is green: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=cdb8f52e8801

Pushed to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/f24d24c42c2b

Comment 16

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/f24d24c42c2b