I use ubuntu linux and my browser is firefox. For quite a long time drag & drop of auction URLs into jbw has been broken. Recently I decided to investigate the cause of this. I am not a java programmer, but java is close enough to C++ to let me understand what’s going on most of the time.

So what I have found so far is that jbw is accepting the drop from the browser containing text/html data. However jbw ends up ignoring the data because TargetDrop::receiveDropString rejects it. The reason it’s rejected is because JHTML::getAllURLsOnPage returns a null list.

The data being passed to receiveDropString looks something like this:

<a href="http://cgi.ebay.com/ADIDAS-PERFORMANCE-Womens-Power-Capri-Athletic-Pants-M-/220593759671?cmd=ViewItem&amp;pt=US_Women_s_Athletic_Apparel&amp;hash=item335c69a5b7">http://cgi.ebay.com/ADIDAS-PERFORMANCE-Womens-Power-Capri-Athletic-Pants-M-/220593759671?cmd=ViewItem&amp;pt=US_Women_s_Athletic_Apparel&amp;hash=item335c69a5b7</a>

Can anybody suggest a way to fix or work around this problem? I really miss being able to use drag & drop with jbw.

It looks like the StringBuffer passed to TargetDrop::receiveDropString() has twice as many UTF-16 characters as it should, with the extras being a ‘\u0000’ after each legitimate character. I added some code to remove the extras and now the data isn’t being rejected anymore and drag and drop finally works on my linux machine!!!

I will leave it to the experts to figure it out why the URL data has the extra null characters and fix jbw the right way. I will be using my hacked jbw until the official one gets fixed.

I started having this problem within the last couple of weeks but I am using Windows. It happens with both Firefox or IE6. I suspect that this is a case where the page format has been changed on some of the eBay servers and as this change gets rolled out into the rest of the servers more people will be affected by it. I just tried DNDing from eBay Motors and it worked but it did not work from another area in regular eBay.

Are your changes small enough that you could post them here?

TIDRIS – any chance I could get a copy of your patched Jbidwatcher for OSX. No drag and drop is driving me NUTS……

frost5709, drag & drop had been broken in linux since I started using jbw on linux a couple of years ago. If your problem started recently, it’s probably due to the new URL format ebay is using for some auctions. It affects pasting URLs as well as dragging URLs into jbw. I believe a fix for the new URL format has already been added into the git repository, so I recommend grabbing the latest code from git and see if it helps.

andama, drag & drop used to work when I was using jbw on OSX a couple of years ago. If your problem started happening recently, see above.

Greetings,
@tidris – Is there any way you can determine what flow it’s taking through the drop handler? Specifically if it’s going through new InputStreamReader(dropStream,"utf-16le"); in JDropListener#getInputStreamData which is one place that it might be adding the bytes incorrectly.

Thanks muchly!

— Morgan Schweers, CyberFOX!

I investigated some more and this is what I found.

-JDropListener::drop() get called with a DropTargetDropEvent object

-drop() gets a Transferable object by calling getTransferable() on the DropTargetDropEvent object

-drop() calls getTransferData() with the Transferable object

-getTransferData() calls testAllFlavors() with the Transferable object and gets a DataFlavor == java.awt.datatransfer.DataFlavor[mimetype=text/html;representationclass=java.io.Reader]

-getTransferData() gets an object that is an instanceof Reader by calling getTransferData() on the Transferable object

-getTransferData() calls getDataFromReader() with a BufferedReader created from the Reader object

-getDataFromReader() calls read() on the BufferedReader object and appends all the chars it gets into a StringBuffer object

-drop() calls receiveDropString() on a TargetDrop object with the StringBuffer created by getDataFromReader().

Thanks, tidris

Greetings,
I posted this on the related ticket but I’ll include it here because it’s useful debugging information, and the answer would be helpful whomever it comes from.

Out of curiosity, what Java version are you using? You can use:

java -version

to tell you.

Also, if you go into JBidwatcher’s ‘Advanced’ configuration, and set a key of ‘debug.uber’ to ‘true’, and do a drag-and-drop operation, the log file should get a complete list of the flavors supported by the dragged object. That would be a helpful list for me to know.

@frost5709 – This is an OS-specific problem; it sounds like you’re getting bit by the ‘eBay changed their URL format’ bug, instead.

— Morgan Schweers, CyberFOX!

Morgan, I added the info you requested to the drag and drop on linux ticket.

any chance I could get a compiled version for OSX that has patched the drag drop issue that started this week after the new ebay changes?

Greetings,
@Tidris I got it; wow. Lots of stuff there; I found a bug that’s probably been in the code forever, too. I’m going to change the order of preference, moving one of the other mime types up, and hopefully that’ll help.

@andama I’m expecting to put out a release tomorrow; I get about 2 hours a weekday to work on JBidwatcher, including email support and coding. Sundays I don’t really get to touch a computer (my day to be 100% active parent and let my wife do anything she wants. Saturdays, however, are nearly entirely dedicated to JBidwatcher and related projects.

I do have a fix all ready for the URL issue on non-Linux platforms. I want to have at least a stab at fixing the Linux problem in the new release. One way or another, I will be putting out a 2.1 (probably pre6) tomorrow, though.

Hope that helps!

— Morgan Schweers, CyberFOX!

I have a suggestion for a possible quick fix in case you can’t figure out how to prevent the nulls from showing up. In TargetDrop::receiveDropString() you are already calling stripNewlines() on the input StringBuffer. Maybe stripNewlines could also take care of removing any null chars it finds. I believe valid html isn’t supposed to have null chars, in which case it should not do any harm to remove nulls in all platforms.

ThanX Morgan!!!!!

Drag and drop for linux is still broken with Saturday night’s code. I posted comments on the ticket.

Greetings,
Yeah, I pulled your code in, instead of mine. I’ll look at the update issues that you raised separately when I can get back to it. I just really had to do the release today, and those are lower priority issues.

— Morgan Schweers, CyberFOX!

I can confirm drag & drog is working on linux with today’s official 2.1pre6 release. Thanks for all the hard work Morgan.

So as I mentioned in the ticket comments, auctions added by dragging aren’t being reported in the Activity log. Also if there is a problem adding the auction (for example, if it’s a duplicate, or there is error talking to ebay, etc), there is no user feedback reporting that.

As an experiment I changed TargetDop::receiveDropString so it now posts to the “user” queue instead of the “drop” queue. The idea is to make a dragged in auction be processed as if it had been pasted in. That change seems to fix the problems I mentioned above, and I haven’t noticed undesirable side effects so far.

I changed this:
MQFactory.getConcrete("drop").enqueueBean(new DropQObject(auctionURL.trim(), mTargetName, true));
to this:
MQFactory.getConcrete("user").enqueue("ADD " + auctionURL);//new

I also changed this:
MQFactory.getConcrete("drop").enqueueBean(new DropQObject(newEntry.trim(), mTargetName, true));
to this:
MQFactory.getConcrete("user").enqueue("ADD " + newEntry);//new