Typing Bug when moving Dillo on DWM's Virtual Desktops
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?? -- Roger http://rogerx.freeshell.org
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. -- Cheers Jorge.-
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? Cheers, Johannes
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). -- -- Rogut?s Sparnuotos
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.
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.-
hi all On Sun, 27 Sep 2009 20:39:45 +0300, Rogut?s Sparnuotos <rogutes@googlemail.com> wrote:
Whenever this bug is triggered, the keyboard behaves as if a modifier was stuck:
seens like the numlock problem i had... try to play with it and other modifiers, like scrool-lock, meta, shifts, etc good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
higuita (2009-09-28 21:49):
hi all
On Sun, 27 Sep 2009 20:39:45 +0300, Rogut?s Sparnuotos <rogutes@googlemail.com> wrote:
Whenever this bug is triggered, the keyboard behaves as if a modifier was stuck:
seens like the numlock problem i had... try to play with it and other modifiers, like scrool-lock, meta, shifts, etc
Thanks for the hint, but I wasn't able to trigger the bug with stuck modifiers while trying out various combinations of them. But I have found a different problem with ScrollLock: whenever the ScrollLock LED is switched on, mouse input behaves as if the first mouse button was pressed (i.e. the mouse becomes unusable). I use ScrollLock with XKB: it is lit when I switch keyboard layouts, and it is configured with this line in xorg.conf: Option "XkbOptions" "grp_led:scroll" -- -- Rogut?s Sparnuotos
participants (6)
-
corvid＠lavabit.com -
higuita7＠yahoo.co.uk -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
rogerx＠sdf.lonestar.org -
rogutes＠googlemail.com