Bugzilla – Full Text Bug Listing
| Summary: | [ui] Can't drag URL into "Add Site" dialog's location field | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Andrew Overholt <overholt> | ||||||
| Component: | p2 | Assignee: | Susan McCourt <susan> | ||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | irbull, leberre, pascal, susan | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux-GTK | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Andrew Overholt
That is odd, I'm seeing the correct behavior on windows. Marking 3.5 to investigate and at least doc. *** Bug 267973 has been marked as a duplicate of this bug. *** Pascal, are you seeing this on Mac or this is a Linux-only problem? Is this related (a dup) of Bug 223991? There is something funny about the setup of this location field because I can drag on the "work with" field of the "available software" dialog but not on the location. (In reply to comment #4) > Is this related (a dup) of Bug 223991? Definitely a platform difference, but this bug deserves special attention. Bug 223991 documents platform differences in drag/drop, stuff we can doc for users. ie, "drag works in X field on Windows, but not Linux" or "different drag sources behave differently on different platforms." This bug is weirder. Andrew and Daniel are seeing that the *name* field accepts the drop, but the location field does not. That is definitely not right. On Windows, it works as expected. Either there's a subtle bug on the wizard code (I looked briefly to make sure I'm setting the drop target on the right widget, but it could be something more subtle), or else a subtle SWT bug. (In reply to comment #5) > There is something funny about the setup of this location field because I can > drag on the "work with" field of the "available software" dialog but not on the > location. > Pascal, on the Mac does the Name field accept the drag? Susan, Just one thought: the difference between the name and the location field is that the location field cannot be empty. I have no idea how this is encoded in java/SWT but could it be a sort of decorator on the field itself, which means that the drop target should be the decorator, not the field? (In reply to comment #7) > Susan, > > Just one thought: the difference between the name and the location field is > that the location field cannot be empty. > > I have no idea how this is encoded in java/SWT but could it be a sort of > decorator on the field itself, which means that the drop target should be the > decorator, not the field? I don't think so. Our UI code is setting up an SWT drop target on the location widget. The enforcement of "can't be empty" is above SWT, in our code. My suspicion is that it somehow involves the widget parentage, but this is just a hunch. My plan is to write an SWT snippet that mimics our usage and if it fails in the same way, we can assume the bug is SWT. If not, then something is subtly wrong in my code... I've double checked my code. The SWT drop target is being set up on the correct widget. My previous hunch was that the widget parentage might be weird, and indeed it was a bit wonky. I changed this to fix a layout problem in bug 268002, so I'm wondering if I happen to have fixed this problem. If not, I'll write an SWT snippet and forward this bug to SWT. Pascal - can you check on the Mac. You should be able to drag a URL from a browser to the location field, but not the name field. Daniel and/or Andrew - can you check on Linux? You'll need the code from HEAD or the 20090416 N-build, or the next I-build to pick up the change I made in bug 268002. I just checked this on linux with the latest from head, and it still doesn't work (for me at least). Created attachment 132173 [details] o.e.equinox.p2.ui patch It seems that our drop targets are not setup the way snippet 284 describes. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet284.java?view=co I used this snippet as a template and it appears to work on Linux now. (I don't know if it still works on Windows :)) Created attachment 132174 [details] o.e.equinox.p2.ui patch It seems that our drop targets are not setup the way snippet 284 describes. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet284.java?view=co I used this snippet as a template and it appears to work on Linux now. (I don't know if it still works on Windows :)) Sorry, I should have said, this isn't a patch to fix it, it just demonstrates that it is possible on Linux. I am looking at the root cause now. It appears that in URLDropAdapter#dropTargetIsValid(DropTargetEvent event) we call URLTransfer.getInstance().nativeToJava(event.currentDataType) and this returns null on linux. If I remove this check, it works fine. (However, I assume this check is here for a reason). On linux it looks like the event.currentDataType is not properly setup until after the drop occurs. This means that we cannot call nativeToJava until after the drop happens. On other platforms I assume this can be called during the drop hover. thanks, Ian... Is it still true that you *can* drag to the name field in the same dialog? That's the part of this bug report that really threw me. Yes, Actually, there is no drop target set for the nickname field, so by default swt text fields must accept text drops. Our drop target on the location field is just a little too restrictive on linux. I'm not sure if this is an SWT bug, or we can just remove the && URLTransfer.getInstance().nativeToJava(event.currentDataType) != null) in the hover event. I guess since there is different behviour on different platforms this is an SWT bug, but for 3.5 it might be easier just to remove this check. (We already check that the text being dropped is a URL). (In reply to comment #15) > Yes, > > Actually, there is no drop target set for the nickname field, so by default swt > text fields must accept text drops. I see....so that's another platform difference. Because on windows the name field doesn't accept a drop (as expected). That is the part that led me to believe this bug was something different. Our drop target on the location field is > just a little too restrictive on linux. I'm not sure if this is an SWT bug, or > we can just remove the > > && URLTransfer.getInstance().nativeToJava(event.currentDataType) != null) > > in the hover event. I guess since there is different behviour on different > platforms this is an SWT bug, but for 3.5 it might be easier just to remove > this check. (We already check that the text being dropped is a URL). > So this is the "prefetch" problem described in bug 223991 (as you first mentioned). I will mark this as a duplicate of that bug. Thanks, Ian, for helping to sort this out. *** This bug has been marked as a duplicate of bug 223991 *** |