Bugzilla – Full Text Bug Listing
|Summary:||Moving focus from clipboard input window to session gets mouse button state out of sync|
|Product:||ThinLinc||Reporter:||Henrik Andersson <firstname.lastname@example.org>|
|Component:||Web Access||Assignee:||Samuel Mannehed <email@example.com>|
|Status:||CLOSED FIXED||QA Contact:||Bugzilla mail exporter <firstname.lastname@example.org>|
|Version:||trunk||Keywords:||ossman_tester, relnotes, upstream|
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
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.
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.
(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.
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
(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.