getComposeDetails() doesn't return information of partially entered email addressess - make getComposeDetails() pillify recipient text [backed out by Bug 1700224]
Categories
(Thunderbird :: Add-Ons: Extensions API, task)
Tracking
(thunderbird_esr78+ wontfix, thunderbird87+ affected)
People
(Reporter: siefkenj, Assigned: TbSync)
References
Details
(Whiteboard: [backed out by Bug 1700224])
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
Open a compose window.
Type an email address in the "to" field but do not press "enter".
Use browser.compose.getComposeDetails(...) to get the details of the message.
Actual results:
The .to attribute is an empty list
Expected results:
.to should contain the partially entered email
This issue confuses users of the MailMerge and MailMergeP extensions. Because these template messages, {{email}} is often entered in the email field. Since this is an invalid email, no autocompletions appear. If a user then clicks the MailMerge button before pressing enter, Thunderbird will report that there is no email address in the "to" field.
|
Assignee | |
Comment 1•5 years ago
|
||
When the entered email has not been turned into a "pill", it is not available. This becoming-a-pill usually happens on focus change.
Alessandro, can I manually trigger the becoming-a-pill function? Could you give me a pointer?
|
||
Comment 2•5 years ago
|
||
Yes, you can do it in various ways.
The easiest one is to call the pillifyRecipients() method:https://searchfox.org/comm-central/rev/0b9e961cd522f59b0bcf7e15062781a87319df2b/mail/components/compose/content/MsgComposeCommands.js#4858-4869
This takes care of going through all the visible addressing fields and converting leftover text to pills, if they're valid addresses.
The other way is to simulate an Enter keypress on a specific input field.
Is there a specific scenario you're trying to cover for?
|
|
Assignee | |
Comment 3•5 years ago
|
||
When users have entered an email address without forcing it to be turned into a pill and then clicking a webextension action button to trigger for example browser.compose.getComposeDetails, it will not return that email address. I am unsure if getComposeDetails itself should call the pillify function or if the action button should do it. I currently think getComposeDetails is the better place.
|
|
Assignee | |
Comment 4•5 years ago
|
||
|
||
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
||
Updated•5 years ago
|
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/4041735c7823
Make getComposeDetails pillify recipients before accessing the values. r=darktrojan
|
|
Assignee | |
Comment 6•5 years ago
|
||
Comment on attachment 9206943 [details]
Bug 1681008 - Make getComposeDetails pillify recipients before accessing the values. r=darktrojan
[Approval Request Comment]
Regression caused by (bug #):
User impact if declined:
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky):
I am evaluating.
|
|
Assignee | |
Updated•5 years ago
|
|
|
||
Updated•4 years ago
|
|
||
Comment 7•4 years ago
|
||
Let's have some clarity here: This bug has been backed out by Bug 1700224.
This bug was trying to solve a problem - non-pillified recipient text not returned by getComposeDetails() API helper function - with a certain solution - pillify non-pillified recipient text whenever getComposeDetails() gets called.
Given that addons may call the function at any time, or even on regular intervals, this turned out to be a bad idea because text entered into recipient input could then pillify at any random time (regression caused by this bug: bug 1696765).
Consequently, this bug was then backed out by bug 1700224.
In conclusion, the original problem of this bug 1681008 - if and how to offer non-pillified recipient text from the UI via getComposeDetails() - has remained unresolved.
Description
•