Program forgets pan button state, gets stuck

[vanessae]

When using the middle button to pan around a board layout, if the pointer is dragged out of PCB's window main, the viewport freezes at the point where the pointer left the window, but PCB remains sort of "stuck" in pan mode. All icons and menu functions within PCB become greyed-out the moment you let go of the button, except for the "mm/mil" button in the upper right corner. To get out of this state, you have to move the mouse back into the window (which causes the viewport to start moving again), middle click somewhere to cancel the pan mode, then try to click and pan again.

Occasionally, when this happens, PCB will get stuck into an unrecoverable pan-and-zoom-only state: assuming the window has focus, the only events the program will recognize in this situation are the movement of the mouse (which always pans), rolling the mouse wheel (which still zooms like usual), clicking on the "mm/mil" button in the upper right corner (which appears to work normally), and using the horizontal and vertical scroll bars (which pans normally). Everything else is greyed-out and ignored. Keyboard events and mouse clicks are otherwise ignored and none of the menus and icons work.

The weird part: The entire layout becomes "selected" (i.e. highlighted in bright cyan) when this happens.

While in this state, it looked like the program ceased writing PCB.xxxxxxx.backup files as well, though I'm not entirely sure what conditions need to be met to
make this auto-save happen.

The only way out when it gets into this state is to close it with the [X] icon in the window title bar. Thankfully, the program offered to save my work, so I didn't lose anything. Interestingly, the "everything is selected" state gets saved into the board file as well.

It's almost as if part of the program is "forgetting" the state of the middle mouse button when the pointer leaves the window. So far it's happened twice with identical results.

What should happen is that PCB should either continue to move the viewport around after the pointer leaves the window, until I let go of the mouse button, or it should cancel the pan mode entirely when the pointer leaves the window. Personally, I'd opt for the former, it's very useful on large or multi-head displays.

This copy of PCB was pulled from CVS about 9 days ago. Using the GTK HID.

[DJ Delorie (djdelorie)]

reproduced in 20100929

[Vanessa Dannenberg (vanessadannenberg)]

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).

[Peter Clifton (pcjc2)]

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....

[Richard Barlow (richardpbarlow)]

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.

[Colin D Bennett (colinb)]

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

[Richard Barlow (richardpbarlow)]

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.

[Richard Barlow (richardpbarlow)]

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.

[Richard Barlow (richardpbarlow)]

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.

[Richard Barlow (richardpbarlow)]

Bump

[Bert Timmerman (bert-timmerman)]

Topic branch LP699309 pushed to upstream.