Project

General

Profile

Bug #11696

Mouse click-through to element below a dropdown list

Added by Huy Hoang 3 months ago. Updated 25 days ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
Start date:
08/15/2017
Due date:
% Done:

100%

Affected Version:
2.2.5
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Sometimes a dropdown list will cover a slider below it, and clicking the mouse to select an option in the dropdown list will also let that click goes through to the slider, resulted in changing the value of the slider.

One example: in White Balance, select "Direct Sunlight". Clicking on the preset list again will have the top of the dropdown overlapping with the sliders. In this case, clicking "Spot" will also change the "blue" slider to around 7.

Another example: in Base Curve, clicking on the fusion list will have "two exposures" over the "exposure shift" slider beneath it. Thus, clicking "two exposures" will likely change the "exposure shift" to around 3.

dt_clickthru_wb_dropdown.png - White Balance - Preset dropdown (23.1 KB) Huy Hoang, 08/15/2017 06:12 PM

dt_clickthru_wb_slider.png - White Balance - Blue slider clicked (13.9 KB) Huy Hoang, 08/15/2017 06:13 PM

dt_clickthru_bc_dropdown.png - Base Curve - Fusion dropdown (18.5 KB) Huy Hoang, 08/15/2017 06:13 PM

dt_clickthru_bc_slider.png - Base Curve - Exposure Shift slider (20.6 KB) Huy Hoang, 08/15/2017 06:13 PM

DT_GUI.png - DT GUI (1.2 MB) Huy Hoang, 08/15/2017 06:43 PM


Related issues

Duplicates darktable - Bug #10862: accidental triggering of options underneath a dropdown in modules Duplicate 01/07/2016

History

#1 Updated by Tobias Ellinghaus 3 months ago

That doesn't happen for me. Do you use Wayland or Mir or something else instead of X11?

#2 Updated by Huy Hoang 3 months ago

Just stock Ubuntu 16.04. Of course it doesn't happen everytime, the click has to line up with the slider below it. I did adjust .config/darktable/darktablerc for font size:

screen_dpi_overwrite=120

Attached is the screenshot of my DT GUI (1920x1080 screen)

#3 Updated by Huy Hoang 3 months ago

Nevermind, the problem happens only with my Logitech G300s mouse. Doesn't happen with my touchpad or another regular mouse. I'll trace it down further, but probably not related to DT. Sorry.

#4 Updated by Huy Hoang 3 months ago

Maybe you can help me troubleshoot this with your knowledge of how DT handles mouse movement and click on DT GUI.

With the G300s mouse, if I click on a dropdown option and keep the mouse button down at the same spot, the slider has not changed yet. The slider will change its value when I release the mouse button (no movement of the cursor).

The mouse's up and down event is normal in Ubuntu's mouse/touchpad testing, double-click works fine. Never had any issue with other applications (Firefox's JS reports single up/down event correctly). Not a button-bounce issue. The mouse is fine with the rest of the system, no mis-click or unintended double-click.

I removed screen_dpi_overwrite option, smaller text, problem still there, so it's probably not related to screen DPI.

This is a gaming mouse with multiple DPI modes. The problem behaves the same for all modes. Perhaps I should just get another mouse for DT :-)

#5 Updated by Roman Lebedev 3 months ago

Huy Hoang wrote:

...

So is it X11, wayland, mir, xwayland, etc?

#6 Updated by Huy Hoang 3 months ago

X11/Xorg

#7 Updated by Roman Lebedev 3 months ago

  • Duplicates Bug #10862: accidental triggering of options underneath a dropdown in modules added

#8 Updated by Roman Lebedev 3 months ago

  • Status changed from New to Duplicate

Normally the other way around, but the newer issue has more stuff

#9 Updated by Roman Lebedev 3 months ago

  • Status changed from Duplicate to New

Huh, redmine did some strange stuff. I only closed #10862, not #11696

#10 Updated by Huy Hoang about 1 month ago

Just FYI, I'm using DT compiled from master branch of 10/14/2017 (commit 487a47132c05a22fa). The mouse doesn't click through any more, and mouse up on the list doesn't select an item from the list neither.

So, this problem has been fixed, not sure when. Thanks much.

#11 Updated by Tobias Ellinghaus about 1 month ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

I'm setting this to "Fixed" for now, even though no one knows what was happening. Should you encounter this again feel free to write here so we can re-open the ticket.

#12 Updated by Huy Hoang about 1 month ago

I spoke too soon, the problem is still there. But the behavior is slightly different with the current version I have (2.3.0+982~g487a471).

For the Logitech G300s: mouse-down on an option of a dropdown list doesn't click through to a slider beneath it. It's the mouse-up that changes the slider. This does not happen to a regular mouse

For both the G300s and a regular mouse: After mouse-down on a dropdown list, keep the mouse-button pressed then hover the mouse cursor around, that will change any slider in that module that the mouse hovers over.

Easiest to test with "Base curve" and "White balance".

#13 Updated by Huy Hoang 30 days ago

I found out how to make the G300s behaves like a normal mouse. "xinput list" shows the G300s as both pointer and keyboard (id=13 and id=12):

@hotplate:~$ xinput list
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                  id=4    [slave  pointer  (2)]
⎜   ↳ DLL0798:00 06CB:7E92 Touchpad               id=14    [slave  pointer  (2)]
⎜   ↳ Logitech G300s Optical Gaming Mouse         id=13    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Video Bus                                   id=7    [slave  keyboard (3)]
    ↳ Video Bus                                   id=8    [slave  keyboard (3)]
    ↳ Power Button                                id=9    [slave  keyboard (3)]
    ↳ Sleep Button                                id=10    [slave  keyboard (3)]
    ↳ Integrated Webcam                           id=11    [slave  keyboard (3)]
    ↳ Intel HID events                            id=15    [slave  keyboard (3)]
    ↳ Intel HID 5 button array                    id=16    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard                id=17    [slave  keyboard (3)]
    ↳ Dell WMI hotkeys                            id=19    [slave  keyboard (3)]
    ↳ Logitech G300s Optical Gaming Mouse         id=12    [slave  keyboard (3)]

So what I did was disabling the keyboard part (id=12):

@hotplate:~$ xinput list-props 12
Device 'Logitech G300s Optical Gaming Mouse':
    Device Enabled (136):    1
    Coordinate Transformation Matrix (138):    1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
    Device Accel Profile (264):    0
    Device Accel Constant Deceleration (265):    1.000000
    Device Accel Adaptive Deceleration (266):    1.000000
    Device Accel Velocity Scaling (267):    10.000000
    Device Product ID (254):    1133, 49734
    Device Node (255):    "/dev/input/event8" 
    Evdev Axis Inversion (268):    0, 0
    Evdev Axis Calibration (269):    <no items>
    Evdev Axes Swap (270):    0
    Axis Labels (271):    "Abs X" (286), "Abs Y" (287), "Abs Misc" (288), "Abs Misc" (288), "Abs Misc" (288), "Abs Misc" (288)
    Evdev Scrolling Distance (273):    0, 0, 0
@hotplate:~$ xinput set-prop 12 136 0

and disabling it permanently in /usr/share/X11/xorg.conf.d/50-logitech-g300s.conf

# disable the keyboard part of G300s to avoid click-thru problem in Darktable
Section "InputClass" 
        Identifier "Disable Logitech G300s keyboard" 
        MatchProduct "Logitech G300s Optical Gaming Mouse" 
        MatchIsKeyboard "on" 
        Option "Ignore" "on" 
EndSection

By disabling its keyboard device, I don't have the click-through on mouse-up anymore. It's behaving like a regular mouse now, holding down the mouse button after clicking then move the mouse around will still move the sliders, but that's an unlikely user behavior/action.

#14 Updated by Roman Lebedev 27 days ago

  • Target version set to 2.4.0

#15 Updated by Tobias Ellinghaus 26 days ago

I wonder, what even do you see in "xev" when clicking and having the keyboard mode enabled? Are any keyboard events generated?

#16 Updated by Huy Hoang 25 days ago

Edited: I need to experience a little more as the problem is now cannot be reproduce consistently in darktable, even with the g300s keyboard mode re-enabled. From what I can tell so far, xev output is the same for both g300s and regular mouse, whether g300s keyboard mode is enabled or not.

With "xinput test", the g300s's keyboard device doesn't generate anything for moving the mouse around, but it does generate these two events on mouse press and release:

motion a[2]=1 
motion a[2]=0

For the g300s, "xinput test" doesn't show anything for those buttons that change DPI for the mouse-device, but does show events for all buttons (including the DPI-changing buttons). I think its keyboard device is mainly for programming the mouse, and I don't have any use for that. I'll report back after further testing.

#17 Updated by Huy Hoang 25 days ago

Just compared closely, xev outputs with g300s keyboard disabled and enabled don't seem to have any difference to me.

G300S keyboard enabled:

ButtonPress event, serial 37, synthetic NO, window 0x3c00001,
    root 0xf5, subw 0x3c00002, time 20588380, (51,49), root:(51,101),
    state 0x10, button 1, same_screen YES

EnterNotify event, serial 37, synthetic NO, window 0x3c00001,
    root 0xf5, subw 0x0, time 20588380, (51,49), root:(51,101),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus YES, state 272

KeymapNotify event, serial 37, synthetic NO, window 0x0,
    keys:  4294967285 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

ButtonRelease event, serial 37, synthetic NO, window 0x3c00001,
    root 0xf5, subw 0x3c00002, time 20588497, (51,49), root:(51,101),
    state 0x110, button 1, same_screen YES

LeaveNotify event, serial 37, synthetic NO, window 0x3c00001,
    root 0xf5, subw 0x0, time 20588497, (51,49), root:(51,101),
    mode NotifyUngrab, detail NotifyInferior, same_screen YES,
    focus YES, state 16

Keyboard disabled:

ButtonPress event, serial 37, synthetic NO, window 0x3600001,
    root 0xf5, subw 0x3600002, time 22213218, (29,42), root:(29,94),
    state 0x10, button 1, same_screen YES

EnterNotify event, serial 37, synthetic NO, window 0x3600001,
    root 0xf5, subw 0x0, time 22213218, (29,42), root:(29,94),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus YES, state 272

KeymapNotify event, serial 37, synthetic NO, window 0x0,
    keys:  4294967285 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

ButtonRelease event, serial 37, synthetic NO, window 0x3600001,
    root 0xf5, subw 0x3600002, time 22213350, (29,42), root:(29,94),
    state 0x110, button 1, same_screen YES

LeaveNotify event, serial 37, synthetic NO, window 0x3600001,
    root 0xf5, subw 0x0, time 22213350, (29,42), root:(29,94),
    mode NotifyUngrab, detail NotifyInferior, same_screen YES,
    focus YES, state 16

However, I don't know how I missed this: when I run darktable from the terminal, with the G300s keyboard enabled, every mouse press and release caused this line to be printed in the terminal:

(darktable:17847): Gdk-CRITICAL **: gdk_device_get_n_axes: assertion 'gdk_device_get_source (device) != GDK_SOURCE_KEYBOARD' failed

I hope the above can give a better clue as to what's happening.

Also available in: Atom PDF