View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010230||MediaMonkey (current)||Framework: Tagging||public||2012-12-14 05:11||2013-12-10 23:03|
|Target Version||4.1||Fixed in Version||4.1|
|Summary||0010230: Drag & Drop Artwork prompts 2 file tag operations (regression)|
|Description||When you drag & drop Artwork onto the Art & Details window you get 2 prompts to tag the files with Artwork.|
Seems to occur only when dragging from Firefox, dragging from Chrome doesn't add the artwork twice.
|Tags||No tags attached.|
|Fixed in build||1678|
I cannot reproduce this. Is it still reproducible in 1615? On clean install? How exactly?
||Yes, this still happens on 1624. Just drag & drop (from Firefox) an image on the Art & Details window.|
Note that it is Firefox issue, Firefox sends the file twice as:
As you can see, the first is direct link and the second is locally cached image.
I tried to eliminate this duplicates by comparing actual picture datas, but the data is different, the former is JPG and the later is BMP.
So there isn't an easy way for MM how to find that these images are same (without pre-converting the images to the same format, but this would bring performance impact).
The same image dragged from Chrome works fine, because Chrome sends only the original link to the image.
||Re-assigning to me to evaluate and find better solution.|
||I'm unable to reproduce in 1657 and FF 23.0.1|
This occurs for me every time with MM 4.1 (tested by dragging AA from firefox to the _Properties_ window). Video posted at:
Debug log posted to ftp.
Note: this is a regression--it doesn't occur with 4.0.7.
Yes, because 4.0.7 does not accept image URL links at all. That said it fails to add image dragged from Chrome, because Chrome sends only URL links (while Firefox sends both URL and local copy).
I guess I could workaround the issue and ignore the URL link in case there are two links (the first is URL link and the second is link to local file, and this way suppose that it is from FireFox), but this will be a dirty hack.
The other issue I see is, that currently MMW doesn't check mime type, it should accept only links with MIME = 'image/*'.
Fixed in build 1678 (implemented both - the dirty hack + MIME checking)