Program forgets pan button state, gets stuck

reproduced in 20100929

Still present in git HEAD as of 2012-01-22.

I have my copy of PCB configured so that its buttons are consistent with GIMP and Inkscape - scroll wheel to zoom, middle-click-and-drag to pan. So for me, it's caused by a simple corner case where it is easy to accidentally roll the scroll wheel a click or two while it is held down for the middle-click-and-drag action.

As before, this applies to the GTK version; not sure if it affects Lesstif.

Test case:

Start PCB, but do not load a layout file - just leave the blank, default layout in place. Middle click and drag to pan. Be sure you mash the button down firmly; you don't want to let it go unintentionally here. While continuing to hold the button down, move the pointer onto the sidebar on the left. Position it between the tool cluster and the layer buttons. Then, while *still holding* the third/middle-click button, roll the scroll wheel a few clicks in either direction.

What happens:

The program gets stuck in this weird pan-and-zoom-only mode as soon as it sees the scroll wheel moving, with only one way out: Hit the Close Window button and let PCB save your layout on the way down, if necessary.

What should happen:

The mouse should, with no exceptions, continue to pan no matter where it moves to - even it ends up on a different monitor - and leave that mode entirely and absolutely when the user lets go of the button. The program should hold focus until the user releases the button (at which point, the program should pass focus back to whatever the window manager says should have it).

Goodness this is an old bug..

But has very good instructions to reporoduce - so shouldn't be too hard to fix.

I thought I'd killed off those "weird state" bugs when I unceremoniously removed the auto-pan code, but this one remained....

I've just reproduced this following Vanessa's test case. However, I also observed something which may aid in tracking down the source of this bug: if you only scroll one step then the UI doesn't lock up, you can click in the drawing area to recover. Scrolling more than one step in either direction causes the UI to lock up.

I confirm that using Vanessa's test case I can lock up the UI. However, I have not seen the entire layout get selected. (I tested it with a non-empty layout to check that point.)

@Richard Barlow:
I confirm your observation that if you scroll only one tick, it will not lock up: if you then right-click in the main drawing area, it recovers to normal mode OK. Scrolling up and then down one click locks up permanently, as does two scroll clicks in the same direction.

I have been experiencing this bug often, but I have never encountered it where it's stuck in pan mode (until using Vanessa's test case). In fact, when it has occured to me in practice:

Things that work:
+ mm/mil toggle button
+ zoom with the mouse scroll wheel
+ pan using the scroll bars
+ see the usual tooltips when I hover over pins/pads

Things that don't work:
- pan using mouse right-click-and-drag
  (it's odd that zoom with scroll wheel works, though)
- no keys are functional... at least these have no effect:
    * zoom with z / Shift+z
    * see any effect from pressing Esc
    * hit Tab to flip the board
    * press '1', '2', etc. to change selected layer
    * press Ctrl+R to get a report dialog

I'm not sure how significant it is but I've just discovered the following after a bit more testing.

The 'oldCursor' global defined in src/hid/gtk/gui-misc.c has three different values depending on the number of scroll steps:

0 steps (just drag over the left-hand area): oldCursor = GDK_X_CURSOR
1 step: oldCursor = GDK_LEFT_PTR
2 steps: oldCursor = GDK_HAND2

I'm sure this in itself isn't the cause of the problem but I imagine it might be useful to know. I'm going to investigate further.

The problem seems to be caused by the 'get_coord' HID command being called multiple times. The GTK HID handles this command in the following way:

If the cursor is within the drawing area then return the current position of the cursor.

If it's not within the drawing area then call the 'run_get_location_loop' function in src/hid/gtk/gui-misc.c, which is the function that disables the majority of the UI (and also sets the cursor to GTK_HAND2).

The 'run_get_location_loop' function runs its own GMainLoop (i'm not an expert but that doesn't seem like a clever thing to be doing) and attaches its own custom handlers for the button_press_even and key_press_even signals. This function seems to work fine in the majority of situations. I.E I can't get "Info->Generate object report" to lock up the UI permanently no matter what I try. In the case of the Zoom command (that is invoked by scrolling), the function is called twice and presumably some sort of deadlock results.

I don't know the best solution to this problem; perhaps the code that handles the scroll wheel should also be disabled in the run_get_location_loop function? Even then I don't see this as being a robust solution as the way this bit of code works seems like it could have lots of corner cases that were never considered when it was written.

The attached patch fixes the UI lock up originally reported. There are still some issues in that you can get into the state where the layout is panning even though you're not holding the mouse button down, but you can now exit this by clicking on the layout.

Bump

Topic branch LP699309 pushed to upstream.