Keys are sometimes interpreted incorrectly

Please paste the output of uzbl-core --bug-info here:

Commit: v0.9.0-21-g4851bae
GTK compile: 3.20.2
GTK run: 3.20.8
WebKit compile: 2.4.10
WebKit run: 2.4.11
WebKit2: 0
libsoup compile: 2.54.0
libsoup run: 2.54.1

Sometimes, in command mode, I press a key and it appears typed out in the status line as opposed to causing the according action.

Also, sometimes when I bring up key hints and then hit the first char of a hint, the action of that char is executed as opposed to being used to filtering the hints that are shown. Example: I bring up key hints. The hint I want to follow is ux. I press u. Bookmarks are opened. The key hint still says ux (as opposed to just x).

Is there a specific website which shows the problem?

No, as far as I can tell any site may be affected at random.

There is some odd parts of bind.py where we do a round trip to core and back that is likely causing this. Because a second key press event might occur before the round trip has finished.

I also noticed:

When I type something in the command bar (e.g. when searching via ddg) and i hit u, sometimes the bookmarks pop up and whatever I had typed is cancelled.

Don't know yet how to reproduce it consistently, but it appears to relate to typing speed: The slower I type, the less likely the error occurs.

ok. if typing speed matters it pretty much has to be this round trip.

I'm guessing the issue with ddg only happens shortly after switching mode into the prompt?

Just tried switching and then typing quickly, but unfortunately couldn't reproduce.

I had played around with JS event managers a bit a while back; maybe that would help for things which are more latency-bound (like key events).

I don't think there is any reason it has to make a round trip so the latency shouldn't really matter. However dispatching quick events in core with javascript could help performance a lot so it might be worth considering for that reason.

I tried adding some tests to the event manager to trigger this but couldn't get it to reproduce. I also tried piping a event stream into uzbl also not triggering the error

test:

event KEY_PRESS '' d
event KEY_PRESS '' d
event KEY_PRESS '' g
event KEY_PRESS '' t

socat - /var/run/user/1000/uzbl/uzbl_socket_4115 < test

This doing that produce the error for any of you?

No. Maybe the system must be under some load to slow things down even further?

On the other hand I don't remember noticing the issue on my slow machine (~10 years old).

Did none of you experience the issue while using uzbl normally so far?

Another observation: I have a cbind za. Sometimes z is taken as command, but when I then press a, it is spelled out in the status line.

hi everyone , I am also facing the same issue in uzbl browser , whenever I type fast in the application which I designed , for every 3rd stroke my cursor is going again to first point

kindly someone help me on this

Any idea on how to further debug this?

It drags the otherwise fast uzbl experience :)

hmm. It's very tricky when I can't see it for myself. Maybe you could try capturing a log of events from when this is happening (using the -p) flag. Maybe they are messed up somehow?

Another thing that could help is event-manager logs with lots of verbosity (-vvv)

but be careful to not include any keypresses from passwords etc if doing this

uzbl_event_log_for_issue_298.txt

Attached is the event log.

Note these bindings from my config:

@cbind  e*   = spawn @scripts_dir/follow.sh \@< uzbl.follow.followLinks("\@follow_hint_keys", "%s", 'click') >\@
@cbind  u  = spawn @scripts_dir/load_url_from_bookmarks.sh

For orientation within the log:

 22. I fire up key hints (e)
 51. command executed
 84. key release (e)
199. key press u ('ua' is the key hint I'm going for)
200. the binding for command 'u' executes, firing up bookmarks (it shouldn't)

(I cannot confirm yet if necessary for reproducing the bug, but I had a second uzbl-window idling in the background.)

This line after "key press e" is very suspicious

EVENT [2456] VARIABLE_SET keycmd str ''

So what happens here is the keycmd is reset so the next key press starts a command line from the empty string. question is where that is coming from.

(edit pasted the wrong event.. there is also a modcmd reset a bit above)

Any guesses or anything else I could investigate to help?

could you try removing

@on_event   ROOT_ACTIVE    event KEYCMD_CLEAR
@on_event   FOCUS_ELEMENT  event KEYCMD_CLEAR

and anything else that migth be running KEYCMD_CLEAR from the config. maybe also any automatic mode switches (not sure if that clears the keycmd)

After an extended period of using uzbl like this, I can confirm that deactivating the event triggers ROOT_ACTIVE and FOCUS_ELEMENT had no effect - the issue persisted.

Then, additionally deactivating @on_event ESCAPE event KEYCMD_CLEAR, it seems the issue is gone. However, I'm not 100 % sure, because without that event usage becomes pretty strange in general.

From now on, I'll try some time exclusively deactivating ESCAPE, while leaving the others active.

Anyway, does that info already help a little?

hmm ok. that's really weird. the ESCAPE event should only happen from pressing Escape (or "Ctrl+[") so unless you are doing that mid sequence I don't see how that should affect anything.

oh but wait. in the logs you are pressing escape right before entering triggering the follow script. and because that does a round trip with the event ESCAPE -> event KEYCMD_CLEAR construct there is a race. So clearing the keycmd by pressing escape happens after the first character pressed after that has been processed.

So I guess what we need to really solve this as a mechanism (and a syntax) for dispatching events from keybinds and on_event rules without the roundtrip. Meaning the event-manager would take care to send and react to those internally.

An initial idea for how this could look. -> replacing = for bind and only allowed as the first token of on_event

@bind <Escape>     -> ESCAPE
@on_event ESCAPE   search clear
@on_event ESCAPE   -> KEYCMD_CLEAR

I suppose that the event manager could inspect the event being sent and see if it has an internal handler and just route it that way instead of sending it to uzbl-core.

IIRC what the event manager sends is only a opaque command string which we make no attempt at understanding. I don't like the idea of making it understand the full uzbl syntax but I guess some sort of middle ground of tokenizing and then checking if the first one is "event" would be fine.

Started hacking a bit on the event manager to try to fix this got the on_event bit to resolve internally without the roundtrip and nothing broke terribly from a quick glance.

WIP https://github.com/keis/uzbl/tree/event-dispatch-without-roundtrip

So with the section from #351 and after adding a bit of for(i=0;i<1000000;i++){}; into the config and holding escape for a bit, releasing and then pressing j now leaves me with a j in the prompt rather than scrolling. Which is kinda what this issue describes right?

Exactly!

(Though here it's irrelevant how long I keep any of the keys pressed.)