GNOME Bugzilla – Bug 765819
GtkRange zoom Divide By Zero
Last modified: 2018-05-02 17:05:55 UTC
If zoom is not active in GtkRange when the initial slider position is determined, then a divide by zero occurs.
Created attachment 327051 [details] [review] Remove Divide By Zero
how do you trigger this code path ?
In the previous code block any time we are not zooming and GTK is starting a slide, zoom is 1.0. Somehow this seems to result in a value in priv->slide_initial_slider_position that is almost, but not quite, MAX_INT. It seems that through an addition overflow at some point the value wraps around to the intended offset. The behavior I was observing that led me here was that occasionally when I started a drag the slider would jump to the low end. This only occurred when I touched the region of the scale where the marks appeared. I noted that this area only appears active on my ARM target using Weston and a touch screen. If I tried to do the same thing on my x86 desktop with a mouse and --gtk-debug=touchscreen. I could also drag past the beginning of the scale and get a mouse_x which was negative. This resulted in an overflow snapping the slider to the upper end. I would suspect root cause to the bad behavior is in the port to my specific architecture. I wasn't trying to bring that part forward here. The reason I thought this might be relevant to the maintainers is that it looks like GTK is depending on rollover behavior associated with a divide by zero.
This seems dodgy indeed
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/618.