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 599937 - ScrolledWindow with mouse grab results in signed 16-bit overflow with EventMotion
ScrolledWindow with mouse grab results in signed 16-bit overflow with EventMo...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkScrolledWindow
2.16.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-10-28 19:00 UTC by Jim Nelson
Modified: 2012-02-21 22:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test program demonstrating bug (1.08 KB, text/x-vala)
2009-10-28 19:00 UTC, Jim Nelson
Details

Description Jim Nelson 2009-10-28 19:00:00 UTC
Created attachment 146443 [details]
Test program demonstrating bug

I'm embedding a DrawingArea in a ScrolledWindow and capturing mouse events. 
When the height of the canvas approaches 0x7FFF and a window grab occurs past
the bottom of the window (hold left button down and the mouse moves below the
window) the EventMotion events report spurious positions that look like a
signed 16-bit overflow.

I've attached a program written in Vala to demonstrate this.  Scroll to the
bottom of the window, press and hold the button somewhere in the window, then
drag the mouse beyond the bottom edge.  The debug output will show the
y-coordinates going from 32767 to -32767.

Note that the EventMotion coordinates are fine when the window grab is not
active, even if the canvas has a height > 0x7FFF.  However, if a window grab
does occur at a taller height, the bug still occurs.  (A height of 0xFFFF will
overflow to 0).

To make this file, install latest Vala (I'm using Vala 0.77) and build with
this command-line:

valac --pkg=gtk+-2.0 test.vala
Comment 1 Jim Nelson 2012-02-21 22:49:06 UTC
Using my old test program I attempted to reproduce this on GTK+ 2.24.6 and 3.2.0.  It no longer produces the behavior I described.