Bug 278056 - vi keybindings interfere with text entry
Summary: vi keybindings interfere with text entry
Alias: None
Product: rekonq
Classification: Applications
Component: general (show other bugs)
Version: latest git snapshot
Platform: Archlinux Linux
: NOR normal
Target Milestone: 0.9
Assignee: Andrea Diamantini
Depends on:
Reported: 2011-07-18 23:07 UTC by Alex Merry
Modified: 2012-02-11 09:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Alex Merry 2011-07-18 23:07:19 UTC
Version:           latest git snapshot (using Devel) 
OS:                Linux

Often, text fields will not accept h, j, k or l characters.  These appear to be stolen by some sort of vi-like keybinding thing.  Clicking on a different text field and then clicking on the original one again allows these characters to be typed again.

Reproducible: Always

Steps to Reproduce:
There are certain places (particularly on sites like Facebook and Flickr that make heavy use of javascript and overlays) where this happens consistently.  For example, if you click a photo on the news feed in FB (so it opens in an overlay), choose to tag the photo and type in the search box, it will be impossible to type the above characters.

Expected Results:  
The characters should all work when in a text field.
Comment 1 Marc Deop 2012-01-06 22:53:01 UTC
I cannot seem to reproduce this. I've tested on facebook as you commented but it works fine for me.

Comment 2 Andrea Diamantini 2012-01-07 09:59:01 UTC
Targetting 0.9...
Comment 3 Andrea Diamantini 2012-01-09 18:04:31 UTC
Git commit 81bf91dc7d81a06de3f5c16c79c34385e0091cbd by Andrea Diamantini, on behalf of Marc Deop.
Committed on 09/01/2012 at 19:04.
Pushed by adjam into branch 'master'.

Let keys autoscroll work also when middle click use is disabled

(adjam's marginal change): let variables have better names
m_isAutoScrollEnabled --> m_isViewAutoScrolling
Related: bug 289588

M  +9    -7    src/webview.cpp
M  +1    -1    src/webview.h

Comment 4 Andrea Diamantini 2012-01-17 15:38:54 UTC
It works for me in 0.8.60. At least I cannot reproduce it. Alex, what about you?
Comment 5 Alex Merry 2012-01-20 09:44:01 UTC
Nope, it seems to be working now.
Comment 6 Andrea Diamantini 2012-01-20 11:36:30 UTC
Ok, targetting as FIXED in a couple of weeks if nothing happens before ;)
Comment 7 Marc Deop 2012-01-20 15:19:56 UTC
I'm sorry to disagree, I can't reproduce this on facebook but it happens in Google+ if you try to comment on a Feed

Debugging with firebug (sorry, I don't like the webkit web inspector ;) ) it seems that the problem is that the comment box is not an "input" field rather than an "editable" <body> tag.

However, this is the only place where I've encountered the problem
Comment 8 Andrea Diamantini 2012-01-22 10:17:40 UTC
Git commit b0d587dff85c404b83e0f5d1b8356d3b9535f3b5 by Andrea Diamantini.
Committed on 20/01/2012 at 23:08.
Pushed by adjam into branch 'master'.

Consider also editable content

M  +4    -3    src/webview.cpp

Comment 9 Andrea Diamantini 2012-02-06 11:24:16 UTC
Talked about in IRC this morning. NOT Fixed. Reopening...

[11:36] <dMaggot> anybody using rekonq with GMail?
[11:41] <damnshock> dMaggot: me
[11:41] <damnshock> sometimes at least
[11:41] <damnshock> why?
[11:43] <dMaggot> damnshock: try this
[11:43] <dMaggot> damnshock: click reply (you won't be replying, so don't worry)
[11:43] <dMaggot> damnshock: change to Plain Text response
[11:44] <dMaggot> damnshock: click somewhere in the message text and try selecting text with Shift + Arrow Keys
[11:44] <dMaggot> damnshock: does that work for you?
[11:45] <damnshock> no, it does not
[11:45] <damnshock> it does if I press ctrl as well
[11:46] <damnshock> we are facing a similar problem that with vi-like navigation
[11:46] <dMaggot> do you know what's the cause?
[11:47] <damnshock> I think that the content is editable
[11:47] <dMaggot> damnshock: you'll also notice you now can't type Shift + <Any Letter> to get a capitalized <Any Letter>
[11:47] <damnshock> dMaggot: yeah, I noticed that
[11:48] <damnshock> dMaggot: as far as I know, the problem is that rekonq thinks it's still in a webpage rather than in an "input" field
[11:48] <damnshock> that's why the vi-like navigation doesn't work and the "shift" thing as well
[11:49] <dMaggot> damnshock: how is that GMail-specific?
[11:49] <damnshock> not gmail's alone
[11:49] <damnshock> it happens in google+ as well
Comment 10 Andrea Diamantini 2012-02-06 11:27:51 UTC
As said in IRC, it is an editable textarea field where the problem occurs
Comment 11 Andrea Diamantini 2012-02-06 18:33:13 UTC
Git commit fc70e29bed896b83736af7115ea35cf453e2f1ae by Andrea Diamantini.
Committed on 06/02/2012 at 19:35.
Pushed by adjam into branch 'master'.

Control content editable text with qtwebkit APIs instead of rude JS...

... and limit its call where it is truly needed. This to prevent
problems with performance

M  +76   -66   src/webview.cpp

Comment 12 Andrea Diamantini 2012-02-11 09:46:49 UTC
it has been fixed in all reported sites in rekonq 0.8.75