After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 125618 - Locate pointer feature eats all Control_[LR] KeyPressed events
Locate pointer feature eats all Control_[LR] KeyPressed events
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: mouse
2.22.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
: 145591 155477 160396 170834 322545 341086 368499 415636 473343 513890 529316 530003 545812 554223 556501 558649 589523 591605 598716 615083 682760 (view as bug list)
Depends on:
Blocks: 524499
 
 
Reported: 2003-10-27 17:41 UTC by Peter Bergmann
Modified: 2012-10-08 11:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
don't eat the key events (569 bytes, patch)
2004-11-28 23:30 UTC, Sebastien Bacher
reviewed Details | Review
Move to KeyPress (1.99 KB, patch)
2009-02-18 16:20 UTC, Gerd Kohlberger
none Details | Review

Description Peter Bergmann 2003-10-27 17:41:58 UTC
Description of Problem:
If the locate pointer feature is activated 
other applications will not receive 
KeyPress events for Control_L and Control_R anymore.

Steps to reproduce the problem:
1. activate locate pointer feature
2. open xev and press/release Control_L/Control_R
3. KeyPress events will not be shown


Actual Results:
Control_[LR] KeyPress events get lost.

Expected Results:
Control_[LR] KeyPress events must be let
through to applications.


How often does this happen? 
always - if locate pointer is activated.

Additional Information:

gnome-settings-mouse.c uses XGrabKey for 
grabbing the Control_L and Conrol_R
keys. 

Correct code must trap a press/release of a key
without intervening key presses, while otherwise
letting through the key events to applications.
Comment 1 Caleb Groom 2004-11-02 06:03:43 UTC
*** Bug 155477 has been marked as a duplicate of this bug. ***
Comment 2 Caleb Groom 2004-11-02 06:03:59 UTC
*** Bug 145591 has been marked as a duplicate of this bug. ***
Comment 3 Sebastien Bacher 2004-11-28 23:30:19 UTC
Created attachment 34254 [details] [review]
don't eat the key events

this patch is used for a month in the Debian package and works fine, permission
to commit ?
Comment 4 Kjartan Maraas 2005-01-06 12:28:53 UTC
I'd say just go ahead if it's known to work.
Comment 5 Sebastien Bacher 2005-01-13 12:36:38 UTC
*** Bug 160396 has been marked as a duplicate of this bug. ***
Comment 6 Teppo Turtiainen 2005-07-16 17:19:19 UTC
*** Bug 170834 has been marked as a duplicate of this bug. ***
Comment 7 Sebastien Bacher 2005-08-07 17:03:27 UTC
Sergey any opinion on this change?
Comment 8 Sebastien Bacher 2005-11-27 11:25:34 UTC
*** Bug 322545 has been marked as a duplicate of this bug. ***
Comment 9 Dev Tugnait 2005-11-27 11:53:26 UTC
this bug was filed in 2003 and is still not fixed? i dont get it i see a patch
here thats not committed, so what is the status?
Comment 10 Sebastien Bacher 2005-11-27 15:08:31 UTC
It's waiting on something knowing about xkb coding to comment
Comment 11 Sergey V. Udaltsov 2005-11-27 20:29:02 UTC
IIRC XGrabKey really intercepts the key in a very impolite manner - all other
apps lose the access to it (I mean no incoming events generated). From the top
of my head, I don't remember nice way of intercepting all keyboard events (so
they would still be available to the apps).
Comment 12 Sebastien Bacher 2006-05-30 10:57:06 UTC
*** Bug 341086 has been marked as a duplicate of this bug. ***
Comment 13 Sebastien Bacher 2006-05-30 11:02:45 UTC
Ubuntu bugs about that:

https://launchpad.net/distros/ubuntu/+source/control-center/+bug/9441

"Nautilus stops responding on copy-drag if 'Locate pointer' mouse feature is enabled

If 'Locate pointer' mouse feature is enabled (Computer->Desktop
preferences->Mouse->Cursors->Locate Pointer), and you try to copy file by
Ctrl+dragging, nautilus will stop responding when you release Ctrl or left mouse
button to drop copy to destination folder. This effectively disables all desktop
operations and panels until nautilus is killed from console.

Exact sequence to reproduce:
0) Enable 'Locate pointer' mouse feature
1) press Ctrl
2) drag file to destinaton
3) release Ctrl or left mouse button
You must FIRST press Ctrl, and THEN begin to drag file - if order is reverse
operation will success."


https://launchpad.net/distros/ubuntu/+source/control-center/+bug/38144

""Highlight pointer when you press control" option breaks firefox cut/copy by keyboard.

Using an up-to-date dapper i368 install, when using the "Highlight pointer when you press control" option in the mouse preferences, you cannot use Ctrl-c to copy or Ctrl-x to cut a substring from the address box or the google search text box in firefox.

Steps to reproduce:
1) Click on System->Preferences->Mouse->Pointers tab
2) Enable "Hilight pointer when you press control" option
3) Run firefox and enter text in the address box
4) Select a subsection of the text with cursor or shift+arrow keys
5) Press Ctrl-c or Ctrl-x

Expected results:
1) The selected text should be copied or cut to the clipboard

Actual Results:
1) The cursor is hilighted due to Ctrl being pressed
2.a) With Ctrl-c the whole of the text in the box is copied to the clipboard instead of just the selected part.
2.b) With Ctrl-x the whole of the text in the box is cut to the clipboard instead of just the selected part.

Further observation:
Text box widgets in form elements on web pages don't show the same buggy behaviour as the address box and google search box.
Other applications (e.g. gedit) don't seem to show the bug.
..."
Comment 14 Jens Granseuer 2007-02-25 16:31:28 UTC
*** Bug 368499 has been marked as a duplicate of this bug. ***
Comment 15 Jens Granseuer 2007-03-02 18:31:22 UTC
The patch doesn't fix the issues I'm seeing.

Even with it applied I cannot Ctrl-select files in the GTK+ file chooser, or items  in the totem playlist, or mails in balsa. And other apps still don't see KeyPress and KeyRelease events for the affected keys.

To fix it, we'd need a way to do non-exclusive key grabs (if possible including the ability to filter). Not sure if the X API offers something like that. At a cursory glance, it doesn't.
Comment 16 Sebastien Bacher 2007-03-07 12:57:50 UTC
*** Bug 415636 has been marked as a duplicate of this bug. ***
Comment 17 Baptiste MATHUS 2007-05-20 14:49:37 UTC
Hi all,

I'm not sure I shouln't report a new bug, since it's related but doesn't seem to be exactly the same problem as above.

I'm using the "Highlight the pointer when you press Ctrl" on Ubutu Feisty, so 2.18, and I'm having problem with multiple lignes selection.

For example, using synaptics (but I also have it inside Eclipse tables), I can't select multiple lines.

Actually, I realized this feature was involved in this problem working on the KPhotoAlbum app: it was making completely buggy the Ctrl-MouseWheel feature to resize the thumbnails...

Thanks
Comment 18 Rémi Cardona 2007-06-14 21:50:00 UTC
Hi all,

Just pinging for updates on this. Any progress or patches to be tested?

Thanks
Comment 19 Jens Granseuer 2008-02-06 19:59:25 UTC
*** Bug 513890 has been marked as a duplicate of this bug. ***
Comment 20 Bastien Nocera 2008-03-26 16:03:11 UTC
I believe that's fixed in gnome-settings-daemon in 2.22 (although it eats some other events, see bug 524499 and bug 523676).
Comment 21 Rémi Cardona 2008-04-08 09:18:43 UTC
Wouldn't it be simpler if gsd used XEvIE for this sort of stuff?
Comment 22 Jens Granseuer 2008-04-22 16:37:18 UTC
*** Bug 529316 has been marked as a duplicate of this bug. ***
Comment 23 Gilles Dartiguelongue 2008-04-22 22:32:37 UTC
I've enabled this for about 3 weeks and 2.22 works pretty well.
Comment 24 Kai Willadsen 2008-07-22 08:18:42 UTC
*** Bug 473343 has been marked as a duplicate of this bug. ***
Comment 25 Jens Granseuer 2008-08-01 16:15:34 UTC
*** Bug 545812 has been marked as a duplicate of this bug. ***
Comment 26 Jens Granseuer 2008-09-29 19:27:09 UTC
*** Bug 554223 has been marked as a duplicate of this bug. ***
Comment 27 Dave Suffling 2008-09-29 20:07:48 UTC
Still broken under Ubuntu Intrepid. (GNOME 2.24.)
Comment 28 Jens Granseuer 2008-10-16 17:13:21 UTC
*** Bug 556501 has been marked as a duplicate of this bug. ***
Comment 29 Jens Granseuer 2008-10-31 17:47:27 UTC
*** Bug 558649 has been marked as a duplicate of this bug. ***
Comment 30 Gerd Kohlberger 2009-02-18 16:18:11 UTC
Hi, I think I've found a simple solution. What about just showing the locate-pointer window on KeyPress events? That way it would be possible to replay the event immediately and not keep the grab until the key is released.

I did a few tests and they all seem to work:
- synaptic (comment #17)
- file chooser and totem playlist (comment #15)
- nautilus drag-copy (comment #13)
- rhythmbox row selection (bug 524499)

I couldn't test media keys. (bug 524499)
Comment 31 Gerd Kohlberger 2009-02-18 16:20:10 UTC
Created attachment 128992 [details] [review]
Move to KeyPress
Comment 32 Jens Granseuer 2009-02-18 18:54:16 UTC
That would be almost too easy...

How does this cope with fast key repeat rates? Any objections against moving to keypress? Getting rid of all these issues would be awesome.
Comment 33 Bastien Nocera 2009-05-08 02:25:29 UTC
From a discussion on IRC about that problem:
<whot> hadess: that's a problem then [that we need to show the cue on releasing Ctrl]. the proto allows you to replay an event, but for passive grabs you cant replay the release. and events you don't replay you won't see in other clients

So the patch above would probably break other things...

Ray mentioned that we should be able to add support for this through AccessX, and add a new event type for us to catch.

Willie, opinion on this?
Comment 34 Willie Walker 2009-05-14 17:05:22 UTC
(In reply to comment #33)
> From a discussion on IRC about that problem:
> <whot> hadess: that's a problem then [that we need to show the cue on releasing
> Ctrl]. the proto allows you to replay an event, but for passive grabs you cant
> replay the release. and events you don't replay you won't see in other clients
> 
> So the patch above would probably break other things...
> 
> Ray mentioned that we should be able to add support for this through AccessX,
> and add a new event type for us to catch.
> 
> Willie, opinion on this?

Eeeks.  I dunno.  It's been years since I've worked on XKB/AccessX.  My opinion is that doing it at the AccessX level doesn't seem quite right, though.  AccessX is about keyboard enhancements rather than providing signals to applications.

However, I believe XKB emits events when modifiers are changed, and I don't believe you need to eat events or require windows to have focus for these events.  As an example, run the xkbwatch application.
Comment 35 Willie Walker 2009-05-14 17:22:22 UTC
(In reply to comment #34)
> Eeeks.  I dunno.  It's been years since I've worked on XKB/AccessX.  My opinion
> is that doing it at the AccessX level doesn't seem quite right, though. 
> AccessX is about keyboard enhancements rather than providing signals to
> applications.

What I meant here was that modifying AccessX to emit a new event for this purpose doesn't seem like the right thing to do.
Comment 36 Owen Taylor 2009-05-18 22:29:42 UTC
Referring to comment 33 - 

I don't think there's any need to replay the release. What seems to need replaying is the sequence:

 <control press> <mouse button press>

At least that's the issue for Nautilus, and  also apparently the problem in bug 524499 (? weird keyboard...). 

The Firefox bug sounds like it's actually watching for the control press event, which is inevitably eaten, rather than looking at the state of the control modifier when it receives the subsequent key press. That should be fixable 
 
 A) Just make firefox look at the modifiers
 B) at the firefox input layer by synthesizing the modifier key press
    if the state changes between events
 C) gnome-settings-daemon could maybe XSendEvent(..., InputFocus, ...) 
    a key press event before replaying the non-matching event.

I think that replaying the mouse events should be possible with modifications along the lines of:

 - For XGrabKey() pass GrabModeSync for pointer_mode
 - When we get the triggering key press, call XGrabPointer() to establish
   a pointer grab, then XAllowEvents with SyncBoth rather than SyncKeyboard.
   (Note that the key grab activation freezes pointer events, but doesn't
   grab the pointer - we need to grab the pointer to receive the pointer
   events and decide if we need to replay them.)
 - When we get a non-matching event, if it's a pointer event, call
   XAllowEvents with ReplayPointer rather than ReplayKeyboard
 - Ungrab the pointer when we get a non-matching event and also when we
   go ahead and run the locate pointer aniation.

(Untested, may be slightly wrong.)

As far as I can tell, the call to ReplayEvents with AsyncKeyboard is extraneous, so doesn't need modification.
Comment 37 Bastien Nocera 2009-07-24 07:57:25 UTC
*** Bug 589523 has been marked as a duplicate of this bug. ***
Comment 38 Jens Granseuer 2009-10-17 13:29:39 UTC
*** Bug 598716 has been marked as a duplicate of this bug. ***
Comment 39 Jens Granseuer 2010-03-08 15:18:13 UTC
*** Bug 591605 has been marked as a duplicate of this bug. ***
Comment 40 Jens Granseuer 2010-04-08 08:17:32 UTC
*** Bug 615083 has been marked as a duplicate of this bug. ***
Comment 41 Bastien Nocera 2010-10-19 15:46:15 UTC
*** Bug 530003 has been marked as a duplicate of this bug. ***
Comment 42 Bastien Nocera 2012-10-08 11:43:34 UTC
*** Bug 682760 has been marked as a duplicate of this bug. ***
Comment 43 Bastien Nocera 2012-10-08 11:45:50 UTC
Fixed with the patch from bug 682760.