Closed Bug 1007040 Opened 10 years ago Closed 10 years ago

Autocomplete for event invitations: Use uppercase and lowercase of name like in addressbook card

Categories

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aryx, Assigned: Fallen)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Daily and Lightning from 20140506 on Windows 8.1 64 bit

When typing a contacts name into the autocomplete field for sending an event invitation and selecting a suggestion, the letters typed remain in theirs cases, but uppercase and lowercase should written like in the addressbook card.
Does this also happen for TB autocomplete, i.e in the compose dialog? If so, this bug will likely be fixed if they fix it and should probably be moved to the Thunderbird component.
(In reply to Philipp Kewisch [:Fallen] from comment #1)
> Does this also happen for TB autocomplete, i.e in the compose dialog?
No, seems to be only in Calendar.
I see this issue with Daily 20140507 in TB composer, too. So suggest to move this bug to TB.
I can't reproduce this with Daily 20140507 on Windows 8.1 Pro 64 bit.

How I tested:

1. Created new profile
2. Created new contact: Firstname "Alpha", Lastname "Omega", email "alphaomega@example.com"
3. Opened new compose window.
4. Typed "al" and pressed Enter.
Actual and expected result: "Alpha Omega <alphaomega@example.com>"
5. Closed compose window.
6. Installed Lightning.
7. Created new event.
8. Open dialog for adding contacts.
9. Typed "al" and pressed Enter.
Expected result: "Alpha Omega <alphaomega@example.com>"
Actual result: "alpha Omega <alphaomega@example.com>"

After closing the invitation dialog, the Calendar Event dialog's attendees list reads "alpha Omega".
I do see this in the composer autocomplete if you autocomplete and TAB to next. If you press enter it's the version found in the AB.
Blocks: 959209
Keywords: regression
The issue also exists with only display name filled (and no first and last name) in address book.

While in composer the case problem exists with confirming the search result by hitting TAB or clicking into the address field, in Lightning invitation dialog it additionally exists with hitting RETURN.

Tested with TB Daily + Lighning Nightly (2014-05-08).
We should look into this for 3.3 if its a quick fix.
Target Milestone: --- → 3.3
See also bug 1012398. Magnus, as you've worked on that bug, do you think it will fix this case too? Anything we have to fix on the Lightning side?
Depends on: 1012398
I'll have to verify that, but IIRC it didn't fix it completely for lightning, which was a bit surprising.
Flags: needinfo?(mkmelin+mozilla)
So bug 1012398 fixes the tab-to-complete case for lightning too, but it does not fix the enter-to-complete case of the invite dialog. That's not broken in thunderbird, so I'm not sure what's going on there.

http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/messengercompose.xul#925
http://mxr.mozilla.org/comm-central/source/calendar/base/content/dialogs/calendar-event-dialog-attendees.xml#46
Flags: needinfo?(mkmelin+mozilla)
Attached patch Fix - v1 (obsolete) β€” β€” Splinter Review
Thanks for checking. I've isolated the Lightning issue, the blur handler is causing trouble and parsing the wrong value. This fixes, along with a few more special cases for name/email combinations.

Decathlon, if you don't have time to review this soon please defer the review to someone else (redDragon maybe?), I'd like to get this into beta 2.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #8444092 - Flags: review?(bv1578)
Comment on attachment 8444092 [details] [diff] [review]
Fix - v1

Philipp, the patch works fine for the issue relate to this bug, except when using the TAB key instead of the ENTER key after edited an attendee. I've not understood if this should be fixed with bug 1012398 or should be considered here (or it has to be considered a minor issue).

The patch introduces a different behavior when entering a list of attendees separated with commas, for example:
  a <a@a.com>, b <b@b.com>
when clicking on the OK button without confirming with the ENTER key, only the first element is added to the list, the others get lost.
Without the patch, when clicking on the OK button, you can see that before closing the dialog every attendee in the list is moved on a new line, the same doesn't happen with the patch.
Setting r- only for this.
Attachment #8444092 - Flags: review?(bv1578) → review-
(In reply to Decathlon from comment #12)
> Comment on attachment 8444092 [details] [diff] [review]
> Fix - v1
> 
> Philipp, the patch works fine for the issue relate to this bug, except when
> using the TAB key instead of the ENTER key after edited an attendee. I've
> not understood if this should be fixed with bug 1012398 or should be
> considered here (or it has to be considered a minor issue).
Yes, this is covered in bug 1012398. If you apply that patch to your build, the tab issue will go away.

> 
> The patch introduces a different behavior when entering a list of attendees
> separated with commas, for example:
>   a <a@a.com>, b <b@b.com>
> when clicking on the OK button without confirming with the ENTER key, only
> the first element is added to the list, the others get lost.
> Without the patch, when clicking on the OK button, you can see that before
> closing the dialog every attendee in the list is moved on a new line, the
> same doesn't happen with the patch.
> Setting r- only for this.
Ah, thanks for the report. I thought I had all of these cases handled, but it seems there is one more. I will test again and figure out a solution.
Attached patch Fix - v2 β€” β€” Splinter Review
This patch was such a pain, so many different events doing different things at the same time. I hope this covers everything. Things I've tested:

* a <a@a.com>, b <b@b.com>, c <c@c.com>
  - With ENTER and TAB
  - With clicking somewhere else
  - With clicking OK

* random input, usually just simple names without an email
  - Mostly with TAB and ENTER

* autocomplete "f" to "Philipp Kewisch <infxxxx@example.com>"
  - With click, TAB and ENTER

* autocomplete "fo" to "foo@example.com"
  - click, tab, enter

* autocomplete "phil" to "Philipp Kewisch <mozilla@kewis.ch>"
  - click, tab, enter
  - NOK: clicking somewhere other than in the autocomplete popup causes 
    the entry to be in lower case. I think this is acceptable, because 
    clicking on the autocomplete entry or with tab/enter works as expected.

Let me know if you find more failing cases. If there is nothing major I think we should push this to comm-beta and fix any remaining cases afterwards on comm-aurora.
Attachment #8444092 - Attachment is obsolete: true
Attachment #8452227 - Flags: review?(bv1578)
I've pushed this to beta so I can do a new beta build with it. 

https://hg.mozilla.org/releases/comm-beta/rev/5b7b46407074

Leaving open for aurora and central and the review.
I tested on trunk in order to have the patch for bug 1012398 already applied.
I can confirm the cases you reported, I add the following issues:

- when writing "ph" to complete "Philipp Kewisch <mozilla@kewis.ch>",
clicking on another row and OK button doesn't get the capital letter. This had been reported by you, I only added the same behavior with the Ok button.

- when writing "ch" the row proposes "ch >> Philipp Kewisch <mozilla@kewis.ch>",
clicking on another row it leaves "ch >> Philipp Kewisch <mozilla@kewis.ch>" in the row and after clicking on OK the attendee is saved as "chPhilipp Kewisch <mozilla@kewis.ch>". The same happens when clicking directly on the Ok button.
It's a bit forced but it might be correct because the user didn't digit the initial of a name but a character inside the name without selecting afterwards the proposed name.

- once entered a few attendees, if you try to cancel one and write a different attendee on the same row, *sometimes* the autocomplete doesn't work. I can't find a precise rule about this behavior, it doesn't happen always but often.

- this is another bug, it doesn't depend on the autocomplete feature (and on this patch), I report here only because I've just realized it while testing and it should be fixed for the beta. When reopening the dialog previously filed with attendees, it's impossible to edit them, the changes are not stored when the dialog is closed again with the OK button. It's a regression, it happens on trunk and beta but it doesn't with LG 2.6.6. I can't find a bug report about this. Approximative regression range:
3.3a1 20140426 works
3.4a1 20140506 fails
-.- I'm about to give up on this one. Unless I find a fix for it in the next few hours, it won't be part of 3.3 and I don't really have time to try to fix it.

Does the patch generally improve the situation or make it worse? Maybe we should just back it out and live with it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ok, I've checked the cases you mentioned and I think its something we can live with for 3.3, its not much worse than before.

I think we should open new bugs for all the issues found here, the two blur cases in one bug.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Comment on attachment 8452227 [details] [diff] [review]
Fix - v2

Review of attachment 8452227 [details] [diff] [review]:
-----------------------------------------------------------------

I just saw this is still in your queue, I don't think a review is needed anymore since its already been released and there have been no complaints that we can't excuse with "well thats a Thunderbird issue". There were some recent fixes to the autocomplete component that may have fixed it for Thunderbird, we should wait until this is backported and see if there are still some Lightning fixes required.
Attachment #8452227 - Flags: review?(bv1578) → review+
Yes, sorry, I wanted to look into a few followup issues, but if I remember correctly MakeMyDay fixed everything I had noticed.
You need to log in before you can comment on or make changes to this bug.