Closed Bug 1261692 Opened 4 years ago Closed 3 years ago

MODIFICATION_FAILED error when decimal separator is comma (Dutch default)

Categories

(Calendar :: Internal Components, defect)

Lightning 4.0.7.1
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
4.7.1.1

People

(Reporter: bugreport, Assigned: MakeMyDay)

Details

Attachments

(1 file)

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

Steps to reproduce:

Add a new item to the calendar on a Axigen mail server in Thunderbird 38.7.1.


Actual results:

It works fine when the decimal separator in Windows in a point. But when it is a comma, I get MODIFICATION_FAILED and the calendar switches to read-only.


Expected results:

The item should have been added to the calendar. I noticed that I received from Axigen mail server an ics file that contained a line: GEO:52.337130;6.650780
When I add an item, thunderbird sent back to the mail server: GEO:ERROR: No Value, causing a 500 error message from the mail server.
It seems that the original line was not parsed right because of the comma as the separator (which should not be used in this case!).

GEO:ERROR: No Value
Can you please attach the complete event which seems to cause the failure? Is this a caldav or webdav account? Can you please also check in the advanced preferences, whether calendar.icaljs is enabled or disabled.
Component: Untriaged → General
Product: Thunderbird → Calendar
Version: 38 Branch → Lightning 4.0.6
Version: Lightning 4.0.6 → Lightning 4.0.7.1
I've been able to reproduce the problem using a local calendar (not on Axigen mailserver). Create a new local calendar. Import the ics that I've listed below. Then export the calendar again to a file. If the format in Windows is set to English/US, the export will contain the correct original GEO line. If you repeat this import/export when the format is set to Dutch, the export will contain GEO:ERROR: No Value. Maybe a reboot is required after switching the number format for it to have the proper effect.

--------------- test.ics -----------------------------
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20150502T180904Z
DTSTAMP:20150502T180904Z
UID:20150415T100816Z-7ff45c19e7c2a138f231b4c6e8cd1bab@www-kwik-fit.kwik-fi
 t.nl
SUMMARY:Auto met kenteken 69-JZZ-3 naar KwikFit
X-MOZ-LASTACK:20150502T180904Z
DTSTART:20150502T083000
DTEND:20150502T093000
GEO:52.337130;6.650780
LOCATION:Windmolen 9\, 7609NN  Almelo
X-MOZ-GENERATION:2
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT30M
DESCRIPTION:Standaard Mozilla-beschrijving
END:VALARM
END:VEVENT
END:VCALENDAR
--------------------------- end ----------------------
Confirming. This is a problem with both backends.

For icaljs this seems to be fixed upstream as the event is parsed properly by the upstream validator [1]. This should be checked again with Daily once bug 1115667 has landed.

For libical the issue [2] is already fixed upsteam [3], so backporting that patch should resolve it for libical.

[1] http://mozilla-comm.github.io/ical.js/validator.html
[2] https://github.com/libical/libical/issues/85
[3] https://github.com/libical/libical/commit/d3623d1f5a9ef3be16bd32e117c0d96f1f9626d2
Status: UNCONFIRMED → NEW
Component: General → Internal Components
Ever confirmed: true
This is the upstream patch for libical. I haven't run a try build yet due to the current bustage, but this seems straight forward.
Assignee: nobody → makemyday
Status: NEW → ASSIGNED
Attachment #8739691 - Flags: review?(philipp)
Attachment #8739691 - Flags: approval-calendar-release?(philipp)
Attachment #8739691 - Flags: approval-calendar-beta?(philipp)
Attachment #8739691 - Flags: approval-calendar-aurora?(philipp)
Comment on attachment 8739691 [details] [diff] [review]
FixFloatHandlingInLibical-V1.diff

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

Thanks for digging that out, r=philipp. As this patch is from upstream and has had time to be tested I'm ok with accepting this for ESR.
Attachment #8739691 - Flags: review?(philipp)
Attachment #8739691 - Flags: review+
Attachment #8739691 - Flags: approval-calendar-release?(philipp)
Attachment #8739691 - Flags: approval-calendar-release+
Attachment #8739691 - Flags: approval-calendar-beta?(philipp)
Attachment #8739691 - Flags: approval-calendar-beta+
Attachment #8739691 - Flags: approval-calendar-aurora?(philipp)
Attachment #8739691 - Flags: approval-calendar-aurora+
Landed on C-C (For 5.1, bmo target milestone currently still missing)

https://hg.mozilla.org/comm-central/rev/5cb34881d913e3eecdcf802a991140ac667a89d5
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Whiteboard: [update target milestone][5.1]
Uplifted up to beta:

https://hg.mozilla.org/releases/comm-aurora/rev/22ffea29a85d33082ff1dee3e7ba35b9a66968ec
https://hg.mozilla.org/releases/comm-beta/rev/0b64a21d681ec1800fcebfe856c5cf3d5732c194

This still needs to be landed on ESR45 once TB 45.1 was released.
Whiteboard: [update target milestone][5.1]
Target Milestone: --- → 4.9
Uplifted to esr45:

https://hg.mozilla.org/releases/comm-esr45/rev/64af6cf4d8b70f71d6c179270590a7c9db6b57f4

Target milestone still needs to be updated.
Whiteboard: [update target milestone][4.7.1.1]
Whiteboard: [update target milestone][4.7.1.1]
Target Milestone: 4.9 → 4.7.1.1
You need to log in before you can comment on or make changes to this bug.