Drag & Drop a contact name from Thunderbird address book (list view) to address box in a new message “compose” window creates two instances of the address in the target address box.

RESOLVED FIXED in Thunderbird 49.0

Status

Thunderbird
Message Compose Window
--
major
RESOLVED FIXED
a year ago
9 months ago

People

(Reporter: rdf@rdfoerster.com, Assigned: Jorg K (GMT+2))

Tracking

({regression})

45 Branch
Thunderbird 49.0
regression
Dependency tree / graph

Thunderbird Tracking Flags

(thunderbird46 wontfix, thunderbird47 fixed, thunderbird48 fixed, thunderbird49 fixed, thunderbird_esr38 unaffected, thunderbird_esr45+ fixed)

Details

(Whiteboard: [relnote-thunderbird])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

a year ago
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: rich909@123.com

  ...the actual result when dropped is:  Richard FoeRichard Foerster <rich909@123.com>rster <rich909@123.com>  
    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 <rich909@123.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 <rich909@123.com>  

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 ???

Updated

a year ago
status-thunderbird46: --- → affected
status-thunderbird47: --- → affected
status-thunderbird48: --- → affected
status-thunderbird49: --- → affected
status-thunderbird_esr38: --- → unaffected
status-thunderbird_esr45: --- → affected
tracking-thunderbird_esr45: --- → ?
Keywords: regression

Comment 1

a year ago
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
Blocks: 1171979
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(bwinton)
(Assignee)

Comment 2

a year ago
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.
Severity: normal → major
status-thunderbird46: affected → wontfix
tracking-thunderbird_esr45: ? → +
Flags: needinfo?(rkent)
(Assignee)

Comment 3

a year ago
Aceman, would you know how to fix this?
Flags: needinfo?(acelists)
(Assignee)

Updated

a year ago
Duplicate of this bug: 1267316
Component: Untriaged → Message Compose Window
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.
Flags: needinfo?(rkent)
Whiteboard: [relnote-thunderbird]
(Assignee)

Comment 6

a year ago
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.

Comment 7

a year ago
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.
(Assignee)

Comment 8

a year ago
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.
(Assignee)

Comment 9

a year ago
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.
(Assignee)

Comment 10

a year ago
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.
Flags: needinfo?(bwinton)
Flags: needinfo?(acelists)

Comment 11

a year ago
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.

Updated

a year ago
Blocks: 1268363
See Also: → bug 1268474
(Assignee)

Comment 12

a year ago
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.
(Assignee)

Comment 13

a year ago
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.
(Assignee)

Comment 14

a year ago
Not sure whether this also caused bug 1268474.
(Assignee)

Comment 15

a year ago
No, bug 1268474 is caused by something else, see bug 1268474 comment #5.
(Assignee)

Comment 16

a year ago
(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.
(Assignee)

Comment 17

a year ago
Created attachment 8747404 [details] [diff] [review]
One line obvious fix (v1).

Once you found it, it's so obvious ;-(
Attachment #8746230 - Attachment is obsolete: true
Flags: needinfo?(mkmelin+mozilla)
Attachment #8747404 - Flags: review?(acelists)
(Assignee)

Updated

a year ago
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
(Assignee)

Updated

a year ago
Blocks: 1269043
(Assignee)

Comment 18

a year ago
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 19

a year ago
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
Attachment #8747404 - Flags: review?(acelists) → review+
(Assignee)

Comment 20

a year ago
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.
(Assignee)

Updated

a year ago
Keywords: checkin-needed
(Assignee)

Comment 21

a year ago
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.
Attachment #8747404 - Flags: approval-comm-esr45?
Attachment #8747404 - Flags: approval-comm-beta?
Attachment #8747404 - Flags: approval-comm-aurora+

Comment 22

a year ago
https://hg.mozilla.org/comm-central/rev/1440d60b09cdb899d10d3c06c7c6f201627f802d
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Keywords: checkin-needed
OS: Unspecified → All
Hardware: Unspecified → All
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 49.0
(Assignee)

Updated

a year ago
status-thunderbird49: affected → fixed
(Assignee)

Comment 23

a year ago
Aurora (TB 48):
https://hg.mozilla.org/releases/comm-aurora/rev/2568b7439abe
status-thunderbird48: affected → fixed
Comment on attachment 8747404 [details] [diff] [review]
One line obvious fix (v1).

http://hg.mozilla.org/releases/comm-esr45/rev/95abafda8ba9
Attachment #8747404 - Flags: approval-comm-esr45? → approval-comm-esr45+

Updated

a year ago
status-thunderbird_esr45: affected → fixed

Comment 25

11 months ago
Comment on attachment 8747404 [details] [diff] [review]
One line obvious fix (v1).

http://hg.mozilla.org/releases/comm-beta/rev/da197f5021a1
Attachment #8747404 - Flags: approval-comm-beta? → approval-comm-beta+

Updated

11 months ago
status-thunderbird47: affected → fixed

Updated

9 months ago
Duplicate of this bug: 1142848
You need to log in before you can comment on or make changes to this bug.