1514126 - contact does not change

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect)

Description

[to302]

Attachment: tb_error_log.png

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

I use korean version TB. (60.3.3 - 32bit on windows 7)
I open address book, and open contact window and edit some data (e.g. name 'hong' to 'kim') then click 'ok' button to save.

I asked support forum. but I can't get solution
https://support.mozilla.org/en-US/questions/1243428?utm_campaign=questions-reply&utm_medium=email&utm_source=notification


Actual results:

click 'ok' button then no action is happen. not close window. not saved. (actually it looks changed in list but when closing and re-open it, it's not changed)

I found error log ( attached image  )
green line is show after launching TB (I do nothing just open console window)
red line is show when i open some contact.
and last one is show when I click 'ok' button



Expected results:

 editing window should be closed and manipulated data must be saved.

Comment 1

[Jorg K (CEST = GMT+2)]

Aceman, can you please take a look.

Comment 2

[:aceman]

I can't reproduce it, whether on trunk or 60.3.3.
In which addressbook is the contact card stored?

Comment 3

[:aceman]

Both of the failing places are this code:
  for (var i = kVcardFields.length; i-- > 0; ) {
    doc.getElementById(kVcardFields[i][0]).value =
      cardproperty.getProperty(kVcardFields[i][1], "");
  }

Do you have an addon touching addressbook?
Can you attach a screenshot of the contact dialog (when editing a contact)?

Comment 4

[to302]

Attachment: contact_window.png

contact window

Comment 5

[to302]

Attachment: contact_dialog2.png

contact dialog 2nd tab

Comment 6

[to302]

Attachment: contact_dialog3.png

contact dialog other tabs image

Comment 7

[to302]

add on 'Note++', 'Enigmail'  and 'Mail Merge'. Mail Merge is installed later after finding bug.

Comment 8

[sfhowes]

Another user had a similar problem that was 'avoided' by reverting to TB 52 (Estonian). It seems to be a bug in certain localizations of TB 60.

Comment 9

[Arrigo Marchiori]

FWIW I found a similar problem and reported it as bug #1521454.

I hope this helps.

Comment 10

[to302]

Today, TB are upgraded to 60.5.0 automatically.
But, Still have same problem.

Comment 11

[Bryan Batten]

I'm having the same problem with thunderbird 60 on devuan ascii linux. Interestingly, the same version of thunderbird is ok on ubuntu 18.04. I also found that downloading version 52.9.1 also resulted in being able to edit contacts. Hope this is helpful, Thanks,

Comment 12

[Bryan Batten]

Oh, and ..

lsb_release -dr
Description: Devuan GNU/Linux 2.0 (ascii)
Release: 2.0
bryan: uname -r
4.14.101

Thunderbird in en-us, I believe.

Comment 13

[Geoff Lankow (:darktrojan)]

I can explain the original report and that in comment 8. According to Pontoon, Korean, Estonian, Albanian have all translated strings labelled "DON'T TRANSLATE" in abCard.dtd. I don't know what we do about that.

Comment 14

[Jorg K (CEST = GMT+2)]

Good on them, as you'd say in Australia:
https://dxr.mozilla.org/l10n-central/search?q=ENTITY+NameField1.id++++file%3AabCard.dtd&redirect=false

And then the software breaks? So this is only for swapping.

You need to file bugs for every affected locale:
Mozilla Localisations :: ko
etc.

and get them to fix that. But that will be hard to get into TB 60 ESR. Or talk to :flod.

Francesco, how can we fix those undesired translations?

Comment 15

[Jorg K (CEST = GMT+2)]

Here's an idea. Get both strings. If the combination isn't "FirstName"/"LastName" or vice-versa, assume that combination. That can be done in code.

Comment 16

[Geoff Lankow (:darktrojan)]

I had that thought, but we're talking about an XML document. It could be done in the JS afterwards, but bonus problem, we can't reference the elements by ID. (Yes I know there are ways around that, just thought I'd point out the irony.)

Comment 17

[Francesco Lodolo [:flod]]

Unfortunately there's literally no way we can ship updates to 60 ESR. As for fixing the broken strings, I suggest to file bugs in each affected locale:
a) I could fix them, but they could be reverted as easily if they're not aware of the problem in the first place
b) I don't really know in which order the fields are supposed to be

I think the main problem is having "DON'T TRANSLATE" strings exposed to localization. Maybe a safer solution would be to have a numeric field that describes the order, instead of field IDs, and a safe fallback value.

On a side note, I assume SeaMonkey is broken as well for those locales.

Comment 18

[Geoff Lankow (:darktrojan)]

Attachment: 1514126-abcard-ids-1.diff

Comment 19

[Magnus Melin [:mkmelin]]

Comment on attachment 9046867 [details] [diff] [review]
1514126-abcard-ids-1.diff

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

I'm not opposed to using this for ESR, but for trunk we should really just fix it properly (have a localizable boolean pref for the order, or perhaps there some even better)

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/84d8d4197737
Fix broken address book contact UI by correcting dodgy translations. r=mkmelin

Comment 21

[Jorg K (CEST = GMT+2)]

Personally I would have checked the 2nd field as well in case they translated one but not the other ;-)

Comment 22

[Jorg K (CEST = GMT+2)]

Filed bug 1531849, bug 1531850 and bug 1531853.

Comment 23

[Jorg K (CEST = GMT+2)]

TB 66 beta 3:
https://hg.mozilla.org/releases/comm-beta/rev/ea9948ac39b0c4a5e26e6c5370e24adf0a9cbd32

Comment 24

[Jorg K (CEST = GMT+2)]

TB 60.6 ESR:
https://hg.mozilla.org/releases/comm-esr60/rev/770071a0ef2e87524d75a123d4cbcbdcc9562363