Well, in this case I'm OK with the fix. On Sep 7, 2012, at 7:32 PM, Alexander Zuev <[email protected]> wrote:
> Leonid, > > if target and source are in the same container then the answer is yes, but i > don't think there is any problem with it. > At least there is no visible side-effect and the corresponding regression > tests and JCK tests are not affected by this change. > If they are in different containers then no event will be delivered to target > until we actually drag there but it is > Ok because the enterEvent will be generated on the native layer and there > will be no need in artificially synthesizing it. > > With best regards, > Alex > > On 9/7/12 19:17, Leonid Romanov wrote: >> Hi, >> Suppose that we are actually outside the target when the drag starts. Do I >> understand correctly that with your change we will get an extra >> processExitMessage() call at the very beginning of the drag? Is it OK? >> >> On Sep 7, 2012, at 6:27 PM, Alexander Zuev <[email protected]> wrote: >> >>> Hello, >>> >>> please review my fix for CR 7171812: [macosx] Views keep scrolling back to >>> the drag position after DnD >>> >>> The reason is that we are wrongly issuing an dragEntered event when we >>> start dragging where drag source and drop target is the same component. It >>> is enough to change the initialization of the insideTarget variable to >>> safely prevent that from happening. >>> >>> Bug description is: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171812 >>> Webrev can be found here: >>> http://cr.openjdk.java.net/~kizune/7171812/webrev.00 >>> >>> With best regards, >>> Alex >
