GNOME Bugzilla – Bug 163414
Mouse button sometimes gets stuck when changing row height
Last modified: 2005-06-27 19:51:25 UTC
This is a strange one. Very probably Windows specific. I noticed that if you left click between two row headers to resize the row height, but release the mouse button right away, the mouse button sometimes "sticks": row height keeps changing even after releasing the mouse button. You have to left click again to stop resizing the row height. Very irritating. It took me a while to figure out how to reliably reproduce this, but this seems to work (sometimes): 1. Exit gnumeric completely 2. Open a new window, don't maximize it 3. Move the mouse pointer outside the Gnumeric window, right next to the row headers (left side) 4. With one quick movement, move the mouse pointer inside the Gnumeric window so that it's between two row headers 5. Don't move the mouse anymore, left click between the row headers 6. If it didn't stick, go back to step 3 (or 1)
Created attachment 35704 [details] test file Rows are very narrow in the attached file to make testing easier. I can also draw a picture if my instructions aren't clear enough :)
This might also have something to do with this bug: I played with attachment 35295 [details] in bug 160343 (save as test.exe) and accidentally noticed that if you move the mouse pointer "too quickly" into the window, clicking the button doesn't work. If you quickly move the pointer back and forth inside and outside the window, you might notice after a while that the button doesn't always work (it cannot be depressed with the mouse). If you're using the Luna theme on Windows XP, it's more obvious: the button borders usually change color when hovering over a button. When clicking doesn't work, the borders don't change either. Also, it seems that native buttons change state more quickly when hovering (color changes instantly), but there's a slight delay with the GTK button if you move the mouse quickly enough over the window.
I think I meant "gets stuck". :)
*** Bug 304186 has been marked as a duplicate of this bug. ***
I've figured out the difference between why this sometimes happens and sometimes doesn't. The problem occurs when the tooltip pops up directly under the mouse cursor, and doesn't occur when the tooltip misses the cursor. You can arrange for this always to happen by enlarging the gnumeric window to reach near to the left of the screen. Most likely the error has to do with the tooltip window eating a mouseup message that gnumeric expected to receive...
Yes, that's it! Thanks for figuring this one out. New recipe, works every time: 1. Maximize Gnumeric window 2. Left click between two row headers 3. Move mouse down Mouse button gets stuck.
ivan any word on this ?
I went through the process of row resizing and found that: 1. click between two rows 2. a toplevel tooltip is created 3. when the left edge of gnumeric is near the left edge of the screen, the tooltip is positioned under the pointer as gnumeric_position_tooltip() clamps x of the tooltip. 4. a GDK_LEAVE_NOTIFY is emitted to the foocanvas and it set its current_item to NULL 5. no event is forwarded to the itembar if the pointer is still left in the area covered by the tooltip. This includes GDK_BUTTON_RELEASE and GDK_MOTION_NOTIFY. It also means that even if you move the pointer up and down inside the tooltip area, the row will not resize. I believe that 4. doesn't happen with gtk+/x11. Even if the tooptip window is positioned under the mouse pointer, the itembar still reacts to GDK_BUTTON_RELEASE and GDK_MOTION_NOTIFY and it means that foocanvas->current_item can't be NULL.
Took the easy way out and just positioned the tooltip to avoid the problem.
As of the 1.5.2-rc2 windows build, there are some (minor) problems left over from this bug. The behaviour is different depending on whether the tooltip pops up under the mouse cursor (as it does when the gnumeric window is close to the left of the screen) or not. Normally, to resize the row you have to drag the resizer. When you release the mouse button, the resizing stops, so a single click has no effect other than to flash the tooltip for a fraction of a second. When the tooltip comes up under the mouse, a single click leaves you resizing the row. To stop resizing, you must move the mouse off of the tooltip to another part of the gnumeric window and then click again. To resize the row a few pixels, you must drag the mouse outside the tooltip window and then back in.
You can also confuse gnumeric into leaving a blank tooltip window around. Start a new gnumeric (1.5.2-rc2), move the window close but not quite at the left edge of the screen, click between two rows. When the tooltip pops up, carefully navigate the mouse across the tooltip to the left out of the gnumeric window, then up and back into the menu bar without crossing the main canvas. Select File->Open and open some spreadsheet. The tooltip will go blank and be stuck hanging around. Again, this is very minor, as you are unlikely to do this accidently and it doesn't lock you out of the interface like the original bug did.