User Agent: Mozilla/5.0 (Windows NT 10.0; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160407164938 Steps to reproduce: Operating system: Win 10-Home Ver: 1511 Build: 10586-218 When you drag and drop a contact entry from the address book (in contact list view) to a “TO” (or other type recipient) address text box the contact first, last name are added to the email address as written in the contact properties with “<” & “>” delimiters added. Then the re-written result is dropped in the text box, but an apparent BUG causes the resulting entry to be duplicated. Actual results: For example, if properties for a contact are: First: Richard Last: Foerster E-Mail: firstname.lastname@example.org ...the actual result when dropped is: Richard FoeRichard Foerster <email@example.com>rster <firstname.lastname@example.org> which appears to be a second copy being inserted within the first copy of the address. Expected results: The re-written result should be: Richard Foerster <email@example.com> NOTE: EXPERIMENTING, I discovered that if this same contact entry from the address book contact listing is dragged and dropped to the message body text block or the subject line text box in the compose window the entry result is as expected: Richard Foerster <firstname.lastname@example.org> If you make an insertion point in the target “TO” address box before dragging an address book entry to the SUBJECT LINE, a SINGLE instance of the email address is correctly written in the target TO box as well as also being written on the subject line. Turning off the OPTION for auto-completion (un-checking the box and accepting the change) DOES NOT alter the duplication problem in the “TO” address text box . ALSO NOTE that if you open the properties view for the target contact, then select the email address and drag and drop it from there to a target TO box the address IS dropped AS ENTERED (not re-written). Possibly related to BUG 295347 ???
Regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f5afaf4e6b72c4b1a20749b4ce7d945add5299f&tochange=abbd213422a560f1180c4ec6e3bf4792c2ea81ba https://hg.mozilla.org/comm-central/pushloghtml?fromchange=8e6a6631f908&tochange=e90ac2142811 Suspect: b0fd980cf36e Magnus Melin — Bug 1171979 - Thunderbird: Change usage of draggesture to dragstart, dragdrop to drop. r=bwinton, Fallen
Ouch, this is a really bad one. Completely destroys the function to drag&drop addresses from the list, either from the contacts sidebar or from the address book in a separate window. Personally, I'd block in this. Kent? Thanks Alice for looking into it so quickly.
Aceman, would you know how to fix this?
Blocking is a pretty severe step, as it also stop other critical fixes from moving forward. This is a broken feature, worth a release note and urgent fix, but I am not going to block the beta/release candidate on it. Note we will not actually build 45.1 for a few days, so if there is a fix for this, and it looks relatively safe, we might still consider adding it to 45.1 But the bar for inclusion is pretty high post-release candidate.
The problem seems to be that the attachment area opens. That doesn't happen in TB 38. If you drop the address onto the attachment area it works, if you drop it into the "To" field, it kind of gets dropped twice, once into the to field which reacts, and the attachment area also seems to react to the drop.
I can see it, but I am not a big friend of drag and drop. We should try Magnus, considering he has done changes in the area.
OK, look here: https://dxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#4364 For all types except text/x-moz-address, the "attachment bucket" (drop area) opens. I've done some debugging, the aFlavour.contentType is dumped out as application/x-moz-file. So that's why the attachment bucket opens. And the stuff gets dropped twice. Let's hope for an easy fix.
That the attachment box opens is due to bug 924530, comment #9, caused by: https://hg.mozilla.org/comm-central/rev/32e405315e3e But even backing this out still gives me a doubled-up address.
Created attachment 8746230 [details] [diff] [review] WIP: Backed out bug 924530 and added debug to investigate Patch to start the investigation. Maybe others have a better idea than me. Frankly, I don't see how bug 1171979 caused this. That bug did a purely mechanical change and copied nsDragAndDrop.js from M-C to C-C.
I don't know if it is worth mentioning this here, but in trying to duplicate this bug I can not in Daily, other than get the attachment pane to open.
I'm not making any progress on this. Finally I decided to back out bug 1171979 which landed this: https://hg.mozilla.org/comm-central/rev/b0fd980cf36e As Alice diagnosed in comment #1, that *fixes* the problem. I don't get it.
OK, here is the story. In bug 1171979 Magnus changed ondraggesture to ondragstart and ondragdrop to ondrop because bug 1162050 was going to remove ondraggesture and ondragdrop. That bug 1162050 has never landed. Functionally ondragstart (eDragStart) and ondraggesture (eLegacyDragGesture) are the same. Functionally ondrop (eDrop) and ondragdrop (eLegacyDragDrop) are *NOT* the same. Ondrop does a whole lot more: https://dxr.mozilla.org/mozilla-central/source/dom/events/EventStateManager.cpp#3416 So I think the way to fix this is to backout bug 1171979 for now.
Not sure whether this also caused bug 1268474.
(In reply to Jorg K (GMT+2) from comment #13) > So I think the way to fix this is to backout bug 1171979 for now. Found a better way, patch coming.
Created attachment 8747404 [details] [diff] [review] One line obvious fix (v1). Once you found it, it's so obvious ;-(
Aceman, just for fun, without the patch, select multiple addresses in the contacts sidebar and drag them to the To field. There you can see the default drop action. All the text contained in those addresses is dropped into the field at the current cursor position. Quite hilarious ;-)
Comment on attachment 8747404 [details] [diff] [review] One line obvious fix (v1). Review of attachment 8747404 [details] [diff] [review]: ----------------------------------------------------------------- Yes, this works for me. The attachment box still opens and stays open. But dragging the card to it does nothing. Also dropping the address to the To field produces: Warning: ReferenceError: reference to undefined property this.popup.popupOpen Source File: chrome://global/content/bindings/autocomplete.xml Line: 96
Thanks for the quick review. (In reply to :aceman from comment #19) > The attachment box still opens and stays open. But dragging the card to it > does nothing. Yes, that's bug 1268238 caused by bug 924530. In bug 924530 Neil added application/x-moz-file to the list of flavours, so in https://dxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#4504 the attachment box opens. Apparently this would be useful to attach an address as vCard file, but that doesn't work. I won't fix this now. > Also dropping the address to the To field produces: > Warning: ReferenceError: reference to undefined property this.popup.popupOpen > Source File: chrome://global/content/bindings/autocomplete.xml > Line: 96 Sigh.
Comment on attachment 8747404 [details] [diff] [review] One line obvious fix (v1). [Approval Request Comment] Regression caused by (bug #): Bug 1171979 User impact if declined: Drag of addresses to composition fields not working. VERY BAD! Testing completed (on c-c, etc.): Manual test. Risk to taking this patch (and alternatives if risky): Not risky. One missing line was added. Very local effect, well understood fix.
Aurora (TB 48): https://hg.mozilla.org/releases/comm-aurora/rev/2568b7439abe
Comment on attachment 8747404 [details] [diff] [review] One line obvious fix (v1). http://hg.mozilla.org/releases/comm-esr45/rev/95abafda8ba9
Comment on attachment 8747404 [details] [diff] [review] One line obvious fix (v1). http://hg.mozilla.org/releases/comm-beta/rev/da197f5021a1