add 18th iteration of classifier

1 files changed, 41 insertions, 0 deletions

diff --git a/results/classifier/118/graphic/2225 b/results/classifier/118/graphic/2225
new file mode 100644
index 00000000..e31b422c
--- /dev/null
+++ b/results/classifier/118/graphic/2225
@@ -0,0 +1,41 @@
+graphic: 0.813
+device: 0.731
+performance: 0.720
+semantic: 0.612
+permissions: 0.394
+peripherals: 0.370
+mistranslation: 0.366
+network: 0.304
+debug: 0.301
+architecture: 0.284
+boot: 0.260
+user-level: 0.250
+arm: 0.246
+PID: 0.216
+vnc: 0.211
+virtual: 0.208
+i386: 0.208
+risc-v: 0.195
+hypervisor: 0.192
+register: 0.186
+VMM: 0.154
+socket: 0.152
+files: 0.152
+kernel: 0.151
+ppc: 0.126
+x86: 0.122
+TCG: 0.118
+KVM: 0.107
+assembly: 0.082
+
+Mouse capture doesn't actually capture (GTK)
+Description of problem:
+The mouse is never actually captured by the window, you can always move it off screen, and because the guest OS has no awareness of the absolute mouse position there are many situations where you can't actually click something in the guest OS because the host mouse cursor is out of the window so clicking clicks on another program's window. It's unusable.
+
+It's clear that the problem is that the cursor isn't actually captured, if it ever was then the problem wouldn't occur. When the mouse is "uncaptured" we see the host cursor at all times and the guest cursor simply doesn't move, but when it's """captured""" the guest cursor still moves freely, it's just hidden while hovering the entire window (and not just the guest rectangle but really the whole thing) and the host cursor moves too at its own pace.
+
+It happens with `-display gtk` but not `-display sdl`.
+Steps to reproduce:
+1. Launch windowed guest
+2. Click on window
+3. Try to move mouse out of the window