Status

Calendar
General
--
critical
RESOLVED FIXED
6 months ago
a month ago

People

(Reporter: Jorg K (GMT+2), Assigned: MakeMyDay)

Tracking

Lightning 5.5
x86
Linux
Dependency tree / graph

Details

(Whiteboard: [Thunderbird-testfailure: X Mac+Linux32])

Attachments

(1 attachment)

(Reporter)

Description

6 months ago
+++ This bug was initially created as a clone of Bug #1325745 +++

Xpcshell failures here on Linux 32 bit, most likely because the date/time format changed due to bug 1301640:
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=a6298203de72b408d580f604e9a336d2b70068bf&selectedJob=55641

TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_ltninvitationutils.js | compareInvitationOverlay_test - [compareInvitationOverlay_test : 537] (test #3): imipHtml-when-content - false == true

In the test we read:
// time format is platform dependent, so we use alternative result sets here
// the first three are to meet configurations running for automated tests, the
// following are some flavours that may occur - if you get a failure for this test,
// add your pattern here
(Reporter)

Comment 1

6 months ago
Note that bug 1301640 has been backed out for now:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a6882a49e907bd01ab7b782a0985614f4565e02e
(Reporter)

Comment 2

6 months ago
Bug 1301640 and bug 1325745 have relanded. So you need to fix this now.
Flags: needinfo?(makemyday)
(Assignee)

Comment 3

6 months ago
Thanks for the heads-up. Test failures on OSX and Linux32 only.
Assignee: nobody → makemyday
Status: NEW → ASSIGNED
Flags: needinfo?(makemyday)
(Assignee)

Comment 4

6 months ago
There seems to more wrong than just the datetime formatting. Currently the test expects for Linux and Mac

<span xmlns="" class="added">Wed 9 Sep 2015 02:00 PM – 03:00 PM</span><br xmlns=""/><span xmlns="" class="removed">Wed 9 Sep 2015 01:00 PM – 02:00 PM</span>"

and 

<span xmlns="" class="added">Wed 9 Sep 2015 2:00 PM – 3:00 PM</span><br xmlns=""/>"<span xmlns="" class="removed">Wed 9 Sep 2015 1:00 PM – 2:00 PM</span>

while dumping the result shows in [1]

<span xmlns="" class="added">Wed 9 Sep 2015 4:08 PM – 3:57 PM</span><br xmlns=""/><span xmlns="" class="removed">Wed 9 Sep 2015 4:20 PM – 4:08 PM</span>

and

<span xmlns="" class="added">Wed 9 Sep 2015 4:08 PM – 3:57 PM</span><br xmlns=""/><span xmlns="" class="removed">Wed 9 Sep 2015 4:20 PM – 4:08 PM</span>

So apart from reformatting, something is wrong with the time itself. That doesn't look like a timezone problem but how we deal with the time in our dateTimeFormatter.

And interestingly, the test passes on Linux64, which I would have expected to fail for the formatting, too, as the date formatting should have been OS but not architecture specific.

[1] https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=94566c4f4b06d1953159f300e15416d2abd9b7cd
(Assignee)

Comment 5

6 months ago
Ok, let's see whether the latest push for bug 1325745 changes the obscure times for Linux32 and Mac:

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=8d851d149b0a588d9ebfed014f6ab806fd5e830a
Version: Trunk → Lightning 5.5
(Assignee)

Comment 6

6 months ago
The obscure time handling is still present (at least on Linux32):

10:19:56     INFO -  PROCESS | 23522 | <span xmlns="" class="added">Wed 9 Sep 2015 4:08 PM – 3:57 PM</span><br xmlns=""/><span xmlns="" class="removed">Wed 9 Sep 2015 4:20 PM – 4:08 PM</span>
(Assignee)

Comment 7

6 months ago
Philipp, do you observe other datetime problems then with the invitation preview on OSX with a current Daily?
Flags: needinfo?(philipp)

Updated

6 months ago
Blocks: 1329841

Updated

6 months ago
No longer blocks: 1329841
(Assignee)

Updated

5 months ago
Blocks: 1329957
(Assignee)

Comment 8

5 months ago
Datepicker on Linux32:

https://bug1329957.bmoattachments.org/attachment.cgi?id=8825470
Severity: normal → critical
Created attachment 8825785 [details]
Linux32 Time-band.png

First I did not get any error messages.
After looking at the date-time-picker with DOM-Inspector, I found these two in the error-console:
>Use of attributes’ nodeValue attribute is deprecated. Use value instead.  lightning-item-iframe.xul
>Use of getAttributeNode() is deprecated. Use getAttribute() instead.  textbox.xml:214:10

I don't know at which point they appeared and could not reproduce them.

Also the times in the Day-View are borked, as can be seen in the Screenshot.

In DOM-Inspector, I found that the xul:datepicker's mValue has the correct date and time set, but the HTML-Input field has 1/1/1970 as value, which is the same as it's defaultValue.
(Reporter)

Comment 10

5 months ago
After landing of bug 1329494, Xpcshell tests are a little greener and these calendar failures are easier to see.

Can someone explain to me why test_ltninvitationutils.js passes on Mac OS X debug but not opt?
(Reporter)

Comment 11

5 months ago
I think you need to dig into the ICU library (intl/locale/DateTimeFormatICU.cpp) and see what happens. Maybe it's buggy.
I traced it down to the timeFormatter.
The following is console output from a linux32 System:

> formatter.FormatTime("", Components.interfaces.nsIScriptableDateFormat.timeFormatNoSeconds, 0, 0, 0);
> "00:37"
> formatter.FormatTime("", Components.interfaces.nsIScriptableDateFormat.timeFormatNoSeconds, 0, 9, 0);
> "00:46"
> formatter.FormatTime("", Components.interfaces.nsIScriptableDateFormat.timeFormatNoSeconds, 0, 23, 0);
> "01:00"
> formatter.FormatTime("", Components.interfaces.nsIScriptableDateFormat.timeFormatNoSeconds, 1, 0, 0);
> "00:25"
> formatter.FormatTime("", Components.interfaces.nsIScriptableDateFormat.timeFormatNoSeconds, 1, 23, 0);
> "00:48"
> formatter.FormatTime("", Components.interfaces.nsIScriptableDateFormat.timeFormatNoSeconds, 9, 0, 0);
> "01:16"
https://dxr.mozilla.org/comm-central/rev/ac3275723df59db0f09198fdb61b51e7002c391a/mozilla/intl/locale/nsScriptableDateFormat.cpp#58

Unfortunately my C++ is not very good...

Comment 14

5 months ago
(In reply to Markus Adrario [:Taraman] from comment #12)

Are you able to reproduce the problem in an official Firefox nightly build? If yes this might be worth reporting as Core problem?

Comment 15

5 months ago
Sure enough, running FormatTime on a Fx 32bit nightly on linux32 boot led to the wrong time. This is definitely a Core bug. The same command in browser console returned the expected "09:00 AM" on Fx64/linux64.

Cc["@mozilla.org/intl/scriptabledateformat;1"].getService(Ci.nsIScriptableDateFormat).FormatTime("", 2, 9, 0, 0);

Seems like time for js to go to Intl.DateTimeFormat, the bugs there (option of 'hour': '2-digit' doesn't return leading 0 as expected) have a better chance though than xpcom interfaces; m-c seems fairly determined to go ICU.
(In reply to Stefan Sitter from comment #14)

Same in the Browser (53.0a1 (2017-01-15) (32-bit):
>Cc["@mozilla.org/intl/scriptabledateformat;1"].getService(Ci.nsIScriptableDateFormat).FormatTime("", 2, 9, 0, 0);
>"01:16"

Comment 17

5 months ago
(In reply to alta88 from comment #15)
> Seems like time for js to go to Intl.DateTimeFormat, the bugs there (option
> of 'hour': '2-digit' doesn't return leading 0 as expected) have a better
> chance though than xpcom interfaces;

This sounds like bug 1284868.
As of this comment [1], the scriptableDateFormat is deprecated. So I fear, we can't expect a fix there - is this correct?
If so, we should consider switching to the new interface Intl.DateTimeFormat.

I could try to prepare that if desired.


[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=421790#c3
Markus, see bug 1229684 for the switch to Intl.DateTimeFormat.
(Reporter)

Comment 20

5 months ago
(In reply to André Bargull from comment #17)
> This sounds like bug 1284868.
Would someone care to explain to me why bug 1284868 of July 2016 is relevant here since the regressing bug 1301640 landed in Jan 2017.
Flags: needinfo?(andrebargull)
(Assignee)

Comment 21

5 months ago
It seems obvious there is still an uncovered bug in the recent implemenation of DateTime formatting in core which breaks Linux 32 (although the code there looks ok to me, but I'm not an expert in cpp). 

But the way forward here is switching to use Intl.DateTimeFormat instead of nsScriptableDateFormat in calendar as the latter is deprecated anyway. There may be still limitations like reported in bug 1284868 we would need to work around to gain formatting capabilities acceptable for calendar client. But we can discuss that in the other bug.

Markus, can you give bug 1229684 a try? My time is quite limited atm. I would leave this bug open for now to fix remaining failures in our tests in case the core issue is uncovered and fixed before landing bug 1229684.
Depends on: 1229684
Flags: needinfo?(Mozilla)
I could have a look at bug 1229684, but I'm not sure if this is really our problem.
There it seems, that only the seconds-display is affected which should be no factor for us here.

First thing we should have bug 1229684 fixed and then see to the rest.
Flags: needinfo?(Mozilla)

Comment 23

5 months ago
(In reply to Jorg K (GMT+1) from comment #20)
> (In reply to André Bargull from comment #17)
> > This sounds like bug 1284868.
> Would someone care to explain to me why bug 1284868 of July 2016 is relevant
> here since the regressing bug 1301640 landed in Jan 2017.

This was in response to the Intl.DateTimeFormat bits in comment #15.
Flags: needinfo?(andrebargull)
(Reporter)

Updated

4 months ago
Whiteboard: [Thunderbird-testfailure: X Mac+Linux32]
(Reporter)

Comment 24

a month ago
With bug 1229684 being fixed, I think we're done here.
Status: ASSIGNED → RESOLVED
Last Resolved: a month ago
Flags: needinfo?(philipp)
Resolution: --- → FIXED
Target Milestone: --- → 5.6
You need to log in before you can comment on or make changes to this bug.