David Keijser

Hey, did a quick poke around with this and it seems to be related to the javascript customizations we do. Removing `uzbl_js_init` from uzbl_init (uzbl-core.c) makes it go again. Not...

Tried asking around on the webkitgtk IRC but no response yet. Disabling that wouldn't disable javascript entirely only the bits run through the js command in the uzbl and clean...

The main difference is that with xinit it's not a child of the wm. I'm not really sure why that would be relevant though. Does the same thing happen if...

uzbl-core is very hard to test (and maybe C in general) but I'm very much a fan of having a test suite when coding. Which is why I really wanted...

That's an interesting idea and with a webserver or maybe a proxy we could intercept everything. It would be testing in more of black box way but that should be...

Sounds like unit tests on one hand and integration (of core) tests on the other, "porque no los dos"? If you want to explore the unit tests route start out...

Agreed. Following the community conventions makes it much easier to jump right in and change some code. However when using pylint we must be aware it sometimes gives false positives...

It would be nice if we could have consistency with the event names but unless we're changing 'newwindow' I don't think we can do that. +1 on forcenewwindow

Looks like github ate some formatting so it's a bit hard to tell what exactly you have as the command. But anyway `o` is already used for another binding so...

Sounds like a bug for sure. The gtkplug/xembed stuff brings some odd quirks to input handling in particular this second set of signals that was just recently fixed. I wonder...