key capturing

[rayfung]

My firefox version is 22.0 and I have just updated vimfx to version 0.5.2.

I found that when I press 't' to open a new tab, firefox will capture that 't' in the newly open tab. 't' appears in the address bar, and I have to delete that 't' every time.

In addition, if my input method (PS: I am Chinese and I have to use pinyin to input Chinese characters) is activated, the character 't' will be captured by my input method. This will slow down the speed and is quite annoying.

[akhodakivskiy]

What other addons/extensions do you have installed? Could you try the same with clean Firefox profile with VimFx installed (and no other extensions)

[rayfung]

I tested it with a clean firefox profile but the problem still exists. However, previous versions (v0.4.8 ...) of vimfx are OK.

[rayfung]

[akhodakivskiy]

There were some breaking changes in FF 24, so we had to reimplement some of keyboard handing in VimFx too. Does he issue also occur if you disable pinyin? Also that popup is it part of Firefox, or is it from pinyin?

[rayfung]

The issue also occurs when input method pinyin is disabled. That popup is from the input method.

[rayfung]

The following screenshot shows the issue when the input method is disabled:

[lydell]

Would you like to test with this experimental version of VimFx? It is compiled from commit f9dd09a in #180 (you can compile it yourself, too, if you want).

[rayfung]

I have tested the experimental version just now and the issue still exists.

[akhodakivskiy]

@rayfung - are you sure that you tested it with clean firefox profile? All the screenshots you posted seem to have other extension icons on the toolbar...

[rayfung]

I tested it with both clean profile and the default profile, the results are the same.

[lydell]

Is only the t command affected? What about o and O for example? What about showing the help dialog while here on github—does that show both VimFx's and github's help dialogs at once?

[rayfung]

Is only the t command affected? What about o and O for example? o and O command also affected when my input method is activated.

What about showing the help dialog while here on github—does that show both VimFx's and github's help dialogs at once? No, only shows VimFx's help dialog.

[lydell]

Ok. So o/O are not affected when your input method is inactivated?

[rayfung]

Yes, not affected, but this only apply to the stable version(v0.5.2). o/O are affected in the experimental version above.

[rayfung]

I install a new Ubuntu(12.04.2) system on VirtualBox just now, and tested VimFx 0.5.2 on Firefox 18.0.2. The issue is the same. I think you can reproduce this bug on virtual machine.

[lydell]

I see.

What is your keyboard layout?

What about focusing a text area with the f command—does the last char of the hint marker for the text area appear in the text area?

[rayfung]

What is your keyboard layout? Ubuntu says it is Chinese, but I think it is the same as English(US).

What about focusing a text area with the f command—does the last char of the hint marker for the text area appear in the text area? (1) if input method is NOT activated, it acts as expected (last char not appears in the text area). (2) if input method IS activated, the last char will be captured by my input method.

[rayfung]

After some tests (on Ubuntu and Fedora), I think I have found the causes. I reinstall Ubuntu and select English locale, then the bug disappears. If I install ibus(Input method framework) and switch input method from 'none' to 'ibus', this bug appears again. So, I think the cause is input method.

[rayfung]

This is not only related to ibus, all other input method I have tested (e.g. fcitx) can cause this problem. This bug only appears when input method process is running. If the process is killed, the bug will disappear.

[lydell]

Nice work!

I just looked through some of the 0.4.8 code. It seems like the keyup event was almost always suppressed. That is not true in later versions. Perhaps that is the cause?

I made a quick modification to the experimental version I linked to above, trying to mimic the 0.4.8 behavior of the keyup event. Would you like to try it out?

[rayfung]

I have tried the modification version, and it does not fix this bug.

[mcomella]

A brief intro on ibus as requested from #191:

ibus is used on Linux as one of several IMEs for foreign language input. I believe it is the default in Ubuntu.

On Arch Linux, getting started requires installing the ibus package as well as an input engine, ibus-hangul, in my case, i.e.:

pacman -S ibus ibus-hangul

Then, launch ibus. I do this via

ibus --daemonize --replace --xim

I honestly do not remember what --xim does though. D: Once it's running, an icon should appear in the system tray, which you can right-click on to select input methods.

I believe all input gets re-routed through ibus, so it's quite probable none of this configuration is necessary to repo this bug.

Finally, several environment variables need to be exported to use ibus:

export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus

Then if Firefox is running, it should be restarted.

The Arch Wiki page on ibus is quite helpful as well.

Please let me know if you have any further questions.

[akhodakivskiy]

I'm going to park the following from #191 in this issue instead:

Interesting, Firefox receives two keydown event in case ibus is active, and the first event has been suppressed with event.preventDefault() and event.stopPropagation(). The issue can be cured by wrapping command code into window.setTimeout(func, 0), but it'd be good to find out what causes two events...

[Hexcles]

Confirmed this bug.

VimFX 0.5.2 Firefox 23.0.1 (Linux x64)

[lydell]

Are those two keydown events identical? Same keyCode for example?

[akhodakivskiy]

Yeah, same key codes

[lydell]

Perhaps we could add a check, something like this:

if lastKeyCode == currentKeyCode and 0 <= timeSinceLastKeydown <= 10
  suppressEvent(event)

[lydell]

We could also wrap command.func(@) into func = command.func.bind(undefined, @); @window.setTimeout(func, 0).

My guess is that the cause of the double event is either a bug in Firefox or ibus, or both.

[Hexcles]

I'm not using ibus, but a simpler input method called "Fcitx". If it has something to do with input methods, the problem might be related to something like XIM, not ibus or fcitx.

2013/9/10 Simon Lydell notifications@github.com

We could also wrap command.func(@) into func = command.func.bind(undefined, @); @window.setTimeout(func, 0).

My guess is that the cause of the double event is either a bug in Firefox or ibus, or both.

— Reply to this email directly or view it on GitHubhttps://github.com/akhodakivskiy/VimFx/issues/188#issuecomment-24151619 .

Hexcles Ma

My Blog: http://robotshell.org/

[rayfung]

this bug gets fixed after updated to firefox 25.0