Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#901 closed bug (fixed)

Drag and drop from ShowImage hangs app + empty clipping

Reported by: darkwyrm Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (9)

comment:1 by leavengood, 13 years ago

Owner: changed from admin to leavengood

in reply to:  description comment:2 by leavengood, 13 years ago

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

comment:3 by leavengood, 13 years ago

Status: newassigned

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.

comment:4 by leavengood, 13 years ago

Resolution: fixed
Status: assignedclosed

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

comment:5 by leavengood, 13 years ago

Resolution: fixed
Status: closedreopened

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.

comment:6 by mmlr, 13 years ago

Owner: changed from leavengood to axeld
Status: reopenednew

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.

comment:7 by mmlr, 13 years ago

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?

comment:8 by axeld, 13 years ago

Resolution: fixed
Status: newclosed

Fixed by hrev20737. Thanks Michael for the hint!

comment:9 by axeld, 13 years ago

Component: - Applications/ShowImageKits/Interface Kit
Note: See TracTickets for help on using tickets.