Uzbl

Tasklist

FS#86 - Command resets on load finish

Attached to Project: Uzbl
Opened by Anonymous Submitter - 2009-08-08 04:38:34 PM
Last edited by Dieter Plaetinck (Dieter_be) - 2009-08-27 07:37:58 PM
Task Type Bug Report
Category uzbl-core
Status Closed
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version Development
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

When the load finish handler gets executed, the sequence of keyboard commands gets interrupted. This can be very frustrating when it forces you to re-type a long command, but it's bloody devastating when your command gets reinterpreted in new and destructive ways.

For example, I bind the 'd' key to close the current window (I have a vimperator background), run uzbl, and while my start page is loading (it takes it a while) I start typing "\wiki debian" (to see what the arch people have to say about real distros ;) - only my command resets right after the space (because an iframe finished loading or something) and uzbl interprets the following 'd' as an "exit" command. Fun fun fun.

The only solution I found is not setting the load finish handler at all, but that kind of sucks.
This task depends upon

Closed by  Dieter Plaetinck (Dieter_be)
2009-08-27 07:37:58 PM
Reason for closing:  Fixed
Additional comments about closing:  keycmd is now not automatically cleared anymore
Comment by Israel Levin (israellevin1) - 2009-08-08 05:32:53 PM
No, my mistake, removing the handler does not solve the problem, so it's probably not the load finish after all.

A good example of a page where this bug is obvious is google.com/ig, with a bunch of widgets, which is exactly my start page.
Comment by Dieter Plaetinck (Dieter_be) - 2009-08-24 10:13:20 AM
I still need to look at the code.

But tom said this on IRC:
holizz> RE this: http://www.uzbl.org/bugs/index.php?do=details&task_id=86 I think it might be an idea to take clear_keycmd() out of load_start_cb, and let people put 'keycmd ' in their start_commit_handlers. Good/bad idea?

That's probably a good idea
Comment by Israel Levin (israellevin1) - 2009-08-26 11:03:35 PM
Thanks, this solves the problem.

Loading...