Drag and drop from ShowImage hangs app + empty clipping

[darkwyrm]

as of hrev19037

Open up a picture in ShowImage, select a section of the picture, and drag it to the desktop. The app will hang and the clipping file will be a 0 byte file.

[leavengood]

This is not a problem when running ShowImage on R5, so it seems to only be a Haiku issue. I suspect this is related to bug #271. I'll check it out on Haiku when I finally get it setup somewhere :)

[leavengood]

This is definitely a problem on Haiku, but again I think it is due to something in the app server drag and drop handling, not ShowImage. But I'll try to do more research.

[leavengood]

I just tested the latest ShowImage on the latest Haiku image and this does not seem to be a problem anymore.

[leavengood]

OK to make things more "interesting" this problem still occurs when I tested on real hardware, but it worked fine within QEMU. I can't say at this point why it did this, all I know what that QEMU was extremely slow so maybe it is some kind of timing issue. But for now I'm reopening this ticket.

[mmlr]

I've tracked down this bug (by checking out different revisions). It worked with hrev18596 while it does not anymore with hrev18605. So I would pinpoint the problem to be caused by hrev18601/hrev18605 which changed the behavior of mouse message handling. Assigning this to Axel as he made the change.

[mmlr]

Finally tracked this down. The cause was introduced in hrev18601 as suggested above. ShowImage calls GetMouse() in a loop to find out when no mouse buttons are pressed anymore:

ShowImageView.cpp:1434

		while (buttons) {
			// Keep reading mouse movement until
			// the user lets up on all mouse buttons
			GetMouse(&point, &buttons);		
			snooze(25 * 1000);
				// sleep for 25 milliseconds to minimize CPU usage during loop
		}

BView::GetMouse() is called here to find the button state. The third argument defaults to true which indicates that the message queue should be scanned. The implementation of GetMouse() then scans the queue and calls BWindow::_StealMouseMessage() (View.cpp:1416) when it finds a suitable message. _StealMouseMessage is supposed to remove the message from the queue, but doesn't if the preferred handler is not the only target of the message (Window.cpp:3037). The message remains in the queue and each call of GetMouse() will return the same values from the same message resulting in an endless loop.

As GetMouse() is documented to remove the message from the queue ​in the R4 BeBook and applications may rely on this behavior we must not return from _StealMouseMessage() without removing the message from the queue. The solution would be to just return false if there are other targets and we cannot remove the message.

Axel could you take a look at that as you introduced said function?

[axeld]

Fixed by hrev20737. Thanks Michael for the hint!