998260 - While Lightning Interface is loading, some properties returns wrong values

Status: NEW

(Calendar :: General, defect)

Description

[Decathlon]

This bug is a regression: Lightning 20140401  works
                          Lightning 20140405  fails
on comm-central there aren't Windows versions between the two dates but there are versions for Mac and Linux, if someone can test on those platforms, the regression range can be reduced.

I don't know how to explain correctly, but it seems that Lightning versions more recent than 20140405 have some problem giving correct values, on the first request, for properties (e.g. sizes) of objects or XUL elements while the interface is loading.

What happens is that if you check some elements while the interface is loading e.g. the width or eight of a box, often a 0 value is returned, instead versions older than 20140401 (at least) always return proper values.

Two examples:

1)
try to check longNameWidth inside the method getLongWeekdayPixels() http://mxr.mozilla.org/comm-central/source/calendar/base/content/calendar-base-view.xml#890

this.longName.boxObject.width is 0 at the first call (the boxObject is not null) but it has the correct value when the method is called afterwards, the same doesn't happen with old versions of Lightning: both the calls returns a correct value.
This issue, combined with a particular code that doesn't allow to unblock a condition, causes a bug in the weekday labels in week view: after *Thunderbird restarts*, the weekday labels always have the long name format (e.g. "Saturday 19 Apr") even when the size of the windows is small and they should have a short name format ("Sat 19 Apr") in order to allow to shrink the columns without an horizontal scrollbar.
This is a good way to find the bug without analyzing code and variables: just restart Thunderbird and you'll see always a long name format in the weekday labels in week-view.
For this particular case I have a fix but it's only a workaround about the code that allows to unblock a conditions, the base issue remains.

2)
try to check the element: scrollbox.boxObject.firstChild.boxObject[propertyName]
inside the method adjustScrollBarSpacers()
http://mxr.mozilla.org/comm-central/source/calendar/base/content/calendar-multiday-view.xml#3680

you can see that when Lightning is loading, adjustScrollBarSpacers() is called twice, the first time the element mentioned above is 0 and the second time it gets the proper value (in my case 17 that is the width of the vertical scrollbar in week view).
With version of Lightning older than 20140401, both the calls return the proper value of 17.
This case doesn't causes any bug because the second time adjustScrollBarSpacers() works correctly, but, for example, if we fix bug 872063, the patch under review there calls the relayout (and hence adjustScrollBarSpacers) only once and the consequence is the missing scrollbarspacer i.e. a misalignment of the weekday headers related to the day columns in week-view.