Bug 6224 - Moving focus from clipboard input window to session gets mouse button state out of sync
Summary: Moving focus from clipboard input window to session gets mouse button state o...
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.9.0
Assignee: Samuel Mannehed
URL:
Keywords: ossman_tester, relnotes, upstream
Depends on:
Blocks:
 
Reported: 2017-04-04 15:41 CEST by Henrik Andersson
Modified: 2017-05-31 13:44 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Henrik Andersson cendio 2017-04-04 15:41:48 CEST 
Reproduce like this:

1. In a session open gedit and create a few lines of text, requires
   only a few char per line

2. Open the clipboard window and enter some text to be copied into
   session

3. While having this clipboard window open, click into session on
   the gedit application and primary paste (middle mouse doesnot work)

When moving around the mouse you will see that only button down went
through to the session and you are in a state were you select texts
in gedit.

This is not reproducible against 4.7.0 on eudemo problem verified using Firefox and Edge on Windows 10 platform
Comment 1 Samuel Mannehed cendio 2017-04-04 15:45:07 CEST 
Can reproduce on Chrome and Firefox on Fedora 25.

(In reply to comment #0)
> This is not reproducible against 4.7.0 on eudemo problem verified using Firefox
> and Edge on Windows 10 platform

I.e. this is a regression in a change done for this release (4.8.0). Should resolve as duplicate once we have identified the change that caused this.
Comment 2 Samuel Mannehed cendio 2017-04-04 15:48:16 CEST 
Easier steps for reproducing:

1. Start a session with a desktop using Web Access
2. Open the clipboard window
3. Click on the desktop and move the mouse (don't hold the click)

You will see that the session believes that you are dragging the mouse.
Comment 3 Samuel Mannehed cendio 2017-04-05 14:20:56 CEST 
(In reply to comment #1)
> I.e. this is a regression in a change done for this release (4.8.0). Should
> resolve as duplicate once we have identified the change that caused this.

Turns out that this is not a regression after all. The confusion stems from changed behavior between GTK2 (which eudemo runs) and GTK3 (which we are using on most servers for testing).

The problem is in fact reproducible against 4.7.0 on eudemo. Use xev to monitor the mouse events and you will see that it is very easy to get button state out of sync.
Comment 4 Samuel Mannehed cendio 2017-04-05 14:25:40 CEST 
The bug lies in faulty logic when sending mouse up events. Web Access has an internal mouse button state which in this case was getting out of sync. The logic always assumed that this state was correct and toggled the state when it should send a mouseUp.

We fixed this upstream now:

https://github.com/novnc/noVNC/commit/270bdbd7fbf3ce24893fa81f22cdfb3d68e91c49
Comment 7 Samuel Mannehed cendio 2017-05-22 11:38:50 CEST 
(In reply to comment #2)
> Easier steps for reproducing:
> 
> 1. Start a session with a desktop using Web Access
> 2. Open the clipboard window
> 3. Click on the desktop and move the mouse (don't hold the click)
> 
> You will see that the session believes that you are dragging the mouse.

A missing part from step 2 is that you also need to click inside the clipboard text box.
Comment 8 Samuel Mannehed cendio 2017-05-22 11:43:25 CEST 
Fixed now.
Comment 9 Pierre Ossman cendio 2017-05-31 13:44:21 CEST 
Works more sanely now with the focus changing click being completely ignored. So no stuck buttons.
Note You need to log in before you can comment on or make changes to this bug.