Wheelscroll while dragging steals mouse click

[Guillermo Espertino (Gez)]

Ubuntu Hardy 8.04 - 64 bit.
It looks like something introduced after Rev. 20069 (I don't have an exact record of when it started to happen but I'm sure it didn't happen before). I can't find a way to reproduce it but it happens too often after dragging the canvas or clicking.
The left click of the mouse stops responding (also the pen tip of the tablet).
It seems to be something related to the xorg input, I guess, because the left click doesn't work on anything else after the problem appears. There is a workaround: If I press alt-a, for instance, the file dialog appears and the mouse click is back.
It happens too often but I couldn't find what triggers that behavior. Maybe is clicking right after panning the canvas, maybe not. I can't tell.

[Guillermo Espertino (Gez) (gespertino-gmail)]

I've found a way to reproduce it. Dragging the canvas with the middle button seems to be producing it.
It's not always, but is quite frequent.

[Guillermo Espertino (Gez) (gespertino-gmail)]

It totally steals the mouse click input. You can't even select another window, task bar button or anything.
A new founding I made is that it only happens in Ubuntu Hardy (8.04), but not in Intrepid (8.10).
I have to check yet if it happens in the 32-bit version too (only tested in 64-bit).
I'm looking in the commit logs. Is it possible that some change introduced in Rev. 20073 is causing this?

[Guillermo Espertino (Gez) (gespertino-gmail)]

It doesn't give any error in the console or the gdb output.

[Guillermo Espertino (Gez) (gespertino-gmail)]

In a recent IRC conversation vlada told me that he has the same problem in Open Suse 11. It has the same GTK+ version than Ubuntu Hardy.

[Vladimir Savic (vladimir-firefly-savic)]

Problem seems to be indeed GTK+ related.

After upgrading to 2.14.4 everything is back to normal.

[mahfiaz (mahfiaz)]

This happens then and only then, then you drag and at dragging scroll the wheel also. And this happening may be related to use of patterns.

Pressing Alt+F to open menu unlocks it.

[LucaDC (lucadc)]

This happens also under Windows XP SP3, Inkscape 0.46+devel, revision 20168, built Nov 10 2008 (latest debugging release).
Selecting and deselecting an object reenables dragging.
About GTK version: libgtkmm-2.4-1.dll and libgtk-win32-2.0-0.dll are the libraries in the program directory. Is there a different way to know the installed version?

[LucaDC (lucadc)]

Sorry, I forgot to say that the problem is only related to the middle mouse, i.e. if you press the middle mouse for dragging nothing happens, then if you select and deselect an object, dragging restarts. It doesn't steal other mouse buttons, only dragging is disabled (for example you can scroll through the wheel or select an object with the left button).

[mahfiaz (mahfiaz)]

For me this happens on intrepid: libgtkmm-2.4-1c2a 1:2.14.1-0ubuntu1, libgtk1.2.10-18.1build2

[mahfiaz (mahfiaz)]

Happens only when snapping enabled.

[Guillermo Espertino (Gez) (gespertino-gmail)]

Good catch Mahfiaz. There was a commit by Diederik Van Lierop around the time the problem started. Probably it was caused by the last changes in the snapping code.

[Diederik van Lierop (mail-diedenrezi)]

Is this still happening with very recent builds? Please test with a revision newer than 20131 (which is of November 3th).

Did the problem really disappear with a new gtkmm lib? Can anyone else than Vladimir confirm this too?

[Guillermo Espertino (Gez) (gespertino-gmail)]

Diederik: I compiled yesterday and the problem is still there.
I checked out in Ubuntu Intrepid (that has newer gtk libraries) and it doesn't hang, but it seems that sometimes the middle click event isn't detected. I think that it's related, because the frequency of the middle click not detected is similar than the frequency of the hangs in Ubuntu 8.04
It only happens with snapping enabled.
Is it possible that the delay of the snapping is obstructing the mouse events? I think that the problem began with that new feature.

[Diederik van Lierop (mail-diedenrezi)]

Once I knew how to reproduce this and saw what was wrong, it was quite easy to fix :-). Please test rev. 20214 or newer, and let me know when it's still broken.

Thanks for all your work people, our combined effort is what makes Inkscape such a great program!

[Diederik van Lierop (mail-diedenrezi)]

BTW, it was exactly problem you predicted, and it was indeed cause by the snapping delay feature.

[Guillermo Espertino (Gez) (gespertino-gmail)]

Diederik: It works perfectly now. Thank you for your work.
I'm really happy to have contributed for the solution. For us (users) this is something that makes us feel proud and part of the project. Thank you for your hard work and for being so kind towards users

[Halley (ed-halley)]

Diederik, this may not be the same bug, but it seems close. On 20808 or so, there's a mouse-freezing bug I am seeing.

* only been able to reproduce it in Node and Pen tools
* locks up regardless of snapping
* locks up even if Node tool's "flashpath" feature is off (which uses a timer)
* locks up if I use a lot of middle-mouse-drag

I'm on OSX using standard X11.app, not Ubuntu. gtkmm @2.10.10_0 (active)

[Diederik van Lierop (mail-diedenrezi)]

I cannot reproduce this, but I might just have fixed this again. Could you please test rev. 20818 or newer?

[Halley (ed-halley)]

Quick (svn up; make) didn't appear to fix the problem. I'll look
at what you changed, and I can give you a large SVG file that (for
me) locks up quite quickly. Some files seem to do it more than others,
perhaps due to number of elements, number of intersections, or
something.

Email me directly (sig below) and I'll share the SVG file offline,
it's not a
file I can post on launchpad.

On Mar 3, 2009, at 4:57 PM, Diederik van Lierop wrote:

> I cannot reproduce this, but I might just have fixed this again. Could
> you please test rev. 20818 or newer?
>
> --
> Wheelscroll while dragging steals mouse click
> https://bugs.launchpad.net/bugs/291795
> You received this bug notification because you are a direct subscriber
> of the bug.

--
[ e d @ h a l l e y . c c ]

[Halley (ed-halley)]

20818 did not seem to fix it, and I found I'm even able to reproduce the problem with an empty canvas.

In event-context.cpp, I added the printf()s:

                printf("state == 0x%08X\n", event->motion.state);
                if ((panning == 2 && !(event->motion.state & GDK_BUTTON2_MASK))
                        || (panning == 1 && !(event->motion.state & GDK_BUTTON1_MASK))
                        || (panning == 3 && !(event->motion.state & GDK_BUTTON3_MASK))
                   ) {
                    /* Gdk seems to lose button release for us sometimes :-( */
                    printf("aborting unterminated pan! 0x%08X\n");
                    panning = 0;
                    sp_canvas_item_ungrab(SP_CANVAS_ITEM(desktop->acetate),
                            event->button.time);
                    ret = TRUE;
                } else {

I found the state was going from 0x00000200 to 0x00000000 unexpectedly, triggering a safety abort of the panning state, but the mouse pointer was not being ungrabbed.

Changing the argument (event->button.time) above to the constant GDK_CURRENT_TIME made this release the mouse more robustly. The item was being ungrabbed, but gdk failed to really release the mouse if the time argument wasn't what it expected to see.

[Diederik van Lierop (mail-diedenrezi)]

I still haven't been able to reproduce this, which obviously makes this very difficult to debug. Could you please describe as detailed as possible the steps needed to reproduce this? And while you're at it, please create a new bug report. This will make sure that this bug report gets the attention it deserves.

BTW, have you tried setting the snap-delay to zero (preferences -> snapping) ? Maybe that makes a difference.

[Diederik van Lierop (mail-diedenrezi)]

Hello Ed (Halley)

This might have been fixed in rev. #20873. The snap-delay mechanism I implemented was resending events without updating the time-stamp. This fix is very similar to your patch, although at another point in the code. Could you please test this?

We might implement your patch anyway, I didn't see any objections on the dev-list.

Thanks,

Diederik

[Halley (ed-halley)]

Thanks, Diederik. I will check this revision.

You may not have realized, I now have commit rights (as id 'speare').
Let's work together to make Inkscape great. ;)

On Mar 9, 2009, at 4:49 PM, Diederik van Lierop wrote:

> Hello Ed (Halley)
>
> This might have been fixed in rev. #20873. The snap-delay mechanism I
> implemented was resending events without updating the time-stamp. This
> fix is very similar to your patch, although at another point in the
> code. Could you please test this?
>
> We might implement your patch anyway, I didn't see any objections on
> the
> dev-list.
>
> Thanks,
>
> Diederik
>
> --
> Wheelscroll while dragging steals mouse click
> https://bugs.launchpad.net/bugs/291795
> You received this bug notification because you are a direct subscriber
> of the bug.

--
[ e d @ h a l l e y . c c ]

[Diederik van Lierop (mail-diedenrezi)]

> You may not have realized, I now have commit rights (as id 'speare').
> Let's work together to make Inkscape great. ;)

Excellent! we could use some hands :-)