On Sun, Sep 27, 2009 at 05:59:47PM +0000, corvid wrote:
Rogut??s wrote:
Johannes Hofmann (2009-09-27 15:31):
On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote:
Hi Roger,
On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote:
I'm finally tackling a typing bug with Dillo, and have found it occurs when moving the Dillo browser to DMW's other virtual desktops.
It doesn't occur when Dillo is first started.
Nothing, if anything at all, shows within gdb.
And, I can't really get to the debug output of DWM as I'm running nvidia proprietary drivers which blanks the terminal once X is started. I do have a laptop for which I can further investigate the DWM debug data, but figured I should post what I know to see if any of you notice similar.
The basic bug scenario, move the Dillo browser to another Virtual Desktop within DWM and start typing (within the url field or within the Google search field.) I notice only certain keys type their characters and most others will either type nothing or may clear the entire field (ie. clear line)
Possible a meta key sticks when moving the browser to another desktop??
It could be a bug in dwm, fltk2 or dillo.
I assume you're using dillo2 (the FLTK2-based one). The dillo UI widgets you describe to fail are plain FLTK2 objects, so please do the following test:
* Get to the fltk2 compilation directory and run test/input program, and then try to reproduce the bug as with dillo.
I quickly tried to reproduce the problem as I also use dwm, but could not see any problem until now. I opened dillo, focused the url field, send dillo to another tag with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and continued typing. This seems to work here. Are you using the mouse maybe?
I've mentioned this bug some months ago and corvid seemed to confirm seeing it. Unfortunately, I still haven't found any way to reliably reproduce it, and what Roger writes doesn't trigger it here. I've seen this bug under dwm and xmonad, haven't used other WM's with dillo.
Whenever this bug is triggered, the keyboard behaves as if a modifier was stuck: keyboard input seems to generate no response, until one tries to type in input boxes (e.g. the location bar). There, typing 'a' goes to the beginning of the line, 'e' goes to the end, etc., as if some modifier was pressed (e.g. try pressing <Ctrl>u, or <Alt>u, or <Mod4>u in the location bar with some text).
Yeah, I can still get into the situation if I play around with modifiers and switching virtual desktops (fvwm) with enough determination and persistence, but it's no longer easy, and when I repeat what I think just made it break, it'll fail to break again.
Hmmm, if it's reproduceable with the test/input program, it's something in FLTK2. If test/input doesn't show the bug, a good test would be to make the location an fltk::Input (instead of CustInput) and try it. If there's no bug, it may be CustInput::handle(). If the bug shows then I'd blame fltk2, but who knows? :-) -- Cheers Jorge.-