View Issue Details

IDProjectCategoryView StatusLast Update
0014102LazarusIDEpublic2011-12-01 11:24
ReporterBrad Campbell Assigned ToMarc Weustink  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version0.9.27 (SVN) 
Fixed in Version0.9.27 (SVN) 
Summary0014102: Alt key gets stuck
DescriptionLinux - i386 GTK2

Steps to reproduce :
Edit anything in source editor.
Alt-tab to other application.
Switch back to lazarus. (Alt-tab or otherwise)
Lazarus now thinks the alt key is held down.
Confirm by dragging mouse around in source editor - Column select mode is active and unable to enter keystrokes.
Fix by using Alt-any-key-the-window-manager-does-not-grab (Alt-A works here)

Reproducible every time.
r20795

Lazarus sees the alt key go down, then the window manager steals focus when the tab key is pressed and lazarus appears to miss the alt-up. From here on in it believes the alt key is still down. A valid alt-key combination resets this state.
TagsNo tags attached.
Fixed in Revision20888
LazTarget-
WidgetsetGTK 2
Attached Files

Relationships

related to 0016165 closedMartin Friebe All editor tabs close unexpectedly except for one I clicked on 

Activities

Vincent Snijders

2009-07-05 16:37

manager   ~0028928

Marc, this may be a regression. If not, feel free to postpone to a later version.

Brad Campbell

2009-07-06 02:12

reporter   ~0028939

This is absolutely a regression. My previous version was r20726 and worked perfectly. Reverting SVN to this and re-compiling makes the problem disappear.

Brad Campbell

2009-07-06 08:48

reporter   ~0028940

Apologies. I just reproduced this under r20726.

Mattias Gaertner

2009-07-06 10:56

manager   ~0028941

20726 works here.
20767 introduced the problem.
20798 still has the problem.

Marc Weustink

2009-07-06 11:31

administrator   ~0028943

:(

Using the X keystate is unreliable, using out own introduces this... I'm not happy

Brad Campbell

2009-07-06 14:16

reporter   ~0028946

Can we just assume key-up for all depressed keys when the application loses focus?

Marc Weustink

2009-07-06 15:22

administrator   ~0028947

Last edited: 2009-07-06 15:24

If I know when an application looses focus yes :)

But there might be a 3rd option. Query the keystates instead if tracking them. I'll have a peek how thats going to work.

Marc Weustink

2009-07-18 18:12

administrator   ~0029162

the keystate is now queried on X or windows

Brad Campbell

2009-07-19 09:36

reporter   ~0029165

It's a lot better, but there is still a problem when alt-tabbing back from an outside application.

Now the alt state can be properly restored by tapping the alt key (whereas before it needed some valid alt-key combination) but on restoration of focus the alt state is still initially incorrect.

Mattias Gaertner

2009-07-19 09:58

manager   ~0029166

your description is exactly the state on ubuntu before the last fix:
switching with alt-tab and back reversed the alt key
any alt-combo was reversed
pressing alt alone fixed the problem.

the last fix solved this.

Brad Campbell

2009-07-19 11:11

reporter   ~0029167

Not here I'm afraid. Prior to r20888 here it worked like this :

Alt-tab away from application, then alt-tab back. Alt key was suck down (not reversed). Application would not respond to a single alt keypress, but using an alt-key combination (I used either alt-a or alt-space) combination would restore things properly when that key combination was released.

With r20892 it works as I described above. The application comes back from Alt-tab with the alt key held down, however now just a single tap on the alt key restores things to normal. All other behaviour is ok.

Brad Campbell

2009-07-19 11:12

reporter   ~0029168

Ooops, I meant to say all testing is on Ubuntu 8.04 i386

Mattias Gaertner

2009-07-19 11:26

manager   ~0029171

I tested on ubuntu 8.04, 8.10 and 9.04 i386 with layout generic 105-key (intl) pc usa and german.

Brad Campbell

2009-07-19 12:29

reporter   ~0029174

The following link points to a binary of an IDE I'm working on that exhibits the behviour I describe above on both my systems.

http://www.fnarfbargle.com/bst/0183/bst-0.18.3.linux.zip

If I could trouble you to try it on one of yours and see if it misbehaves, perhaps it might help me figure out if the problem is local to my system and where it might be.

Just load a text file in the editor and try the selection behaviour. I can reliably reproduce it going to column select mode here after an alt-tab, however a quick tap of the tab key solves it. Vanilla lazarus exhibits the same behaviour here. This was all compiled against r20892.

Brad Campbell

2009-07-20 05:45

reporter   ~0029181

Further testing shows that pressing _any_ key after the return to focus sets the alt-key position correctly. Therefore it _only_ manifests itself if the first action after a return to focus is a left click drag in the editor window. (Which just happened to be my test case).

Marc Weustink

2009-08-03 16:51

administrator   ~0029497

Last edited: 2009-08-03 16:53

Keystate on mousepress is a different issue. On keypress, the state of the alt key is determined by the presence of a syskey flag. On mousepress, the VK_MENU keystate is queried. (which it tracked localy by the widgetset and suffers from the same problem)
(BTW, this is not a regression, older versions behave the same)

Brad Campbell

2009-08-03 18:56

reporter   ~0029498

No worries. Aside from that one issue its working excellently. Close it if you like :) Many thanks for the fix.

Marc Weustink

2009-09-03 17:27

administrator   ~0030380

Alt issue is fixed.
I'm not closing it since in theory it can happen for other keys too.

Paul Ishenin

2010-07-13 05:00

manager   ~0039293

If it is fixed then better to close. At least I changed the target.

Issue History

Date Modified Username Field Change
2009-07-05 14:45 Brad Campbell New Issue
2009-07-05 14:45 Brad Campbell Widgetset => GTK 2
2009-07-05 16:37 Vincent Snijders LazTarget => 0.9.28
2009-07-05 16:37 Vincent Snijders Note Added: 0028928
2009-07-05 16:37 Vincent Snijders Assigned To => Marc Weustink
2009-07-05 16:37 Vincent Snijders Status new => assigned
2009-07-05 16:37 Vincent Snijders Target Version => 0.9.28
2009-07-06 02:12 Brad Campbell Note Added: 0028939
2009-07-06 08:48 Brad Campbell Note Added: 0028940
2009-07-06 10:56 Mattias Gaertner Note Added: 0028941
2009-07-06 11:31 Marc Weustink Note Added: 0028943
2009-07-06 14:16 Brad Campbell Note Added: 0028946
2009-07-06 15:22 Marc Weustink Note Added: 0028947
2009-07-06 15:24 Marc Weustink Note Edited: 0028947
2009-07-18 18:12 Marc Weustink Fixed in Revision => 20888
2009-07-18 18:12 Marc Weustink Status assigned => resolved
2009-07-18 18:12 Marc Weustink Fixed in Version => 0.9.27 (SVN)
2009-07-18 18:12 Marc Weustink Resolution open => fixed
2009-07-18 18:12 Marc Weustink Note Added: 0029162
2009-07-19 09:36 Brad Campbell Status resolved => assigned
2009-07-19 09:36 Brad Campbell Resolution fixed => reopened
2009-07-19 09:36 Brad Campbell Note Added: 0029165
2009-07-19 09:58 Mattias Gaertner Note Added: 0029166
2009-07-19 11:11 Brad Campbell Note Added: 0029167
2009-07-19 11:12 Brad Campbell Note Added: 0029168
2009-07-19 11:26 Mattias Gaertner Note Added: 0029171
2009-07-19 12:29 Brad Campbell Note Added: 0029174
2009-07-20 05:45 Brad Campbell Note Added: 0029181
2009-08-03 16:51 Marc Weustink Note Added: 0029497
2009-08-03 16:53 Marc Weustink Note Edited: 0029497
2009-08-03 18:56 Brad Campbell Note Added: 0029498
2009-09-03 17:27 Marc Weustink LazTarget 0.9.28 => 0.9.30
2009-09-03 17:27 Marc Weustink Note Added: 0030380
2009-09-27 11:14 Vincent Snijders Target Version 0.9.28 => 0.9.30
2010-03-31 14:31 Martin Friebe Relationship added related to 0016165
2010-07-13 05:00 Paul Ishenin LazTarget 0.9.30 => -
2010-07-13 05:00 Paul Ishenin Note Added: 0039293
2010-07-13 05:00 Paul Ishenin Target Version 0.9.30 =>
2010-08-08 17:10 Marc Weustink Status assigned => resolved
2010-08-08 17:10 Marc Weustink Resolution reopened => fixed
2011-12-01 11:24 Marc Weustink Status resolved => closed