Closed Bug 1022120 Opened 6 years ago Closed 5 years ago

Week-view: labels in the day headers don't change from long to short format

Categories

(Calendar :: Calendar Views, defect)

Lightning 3.3
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bv1578, Assigned: bv1578)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Steps to reproduce:

- create a new profile or delete the content of the file localstore.rdf in the profile folder;
- open Thunderbird, select the week view. When resizing horizontally the view, the labels in the day headers change from the short format (e.g. Sat. 10 May) to the Long format (Saturday 10 May) according to the room available horizontally, eventually close the today-pane to see it more easily.
- close and restart Thunderbird.

Actual result:

After Thunderbird has restarted, the labels have the long format and don't change anymore when resizing the window. The day columns have a minimum width that allows the labels to stay in long format and don't get smaller; the horizontal scrollbar appears when the view is still relatively wide.
Attached patch patch - v1 (obsolete) — Splinter Review
This bug is a consequence of bug 998260 (see first example in description there) along with a flaw present in the method getLongWeekdayTotalPixels
http://mxr.mozilla.org/comm-central/source/calendar/base/content/calendar-base-view.xml#601

The method sets the field mLongWeekdayTotalPixels to the right value according to the size of some elements, but it does the assignment only the first time is called (when mLongWeekdayTotalPixels is -1).
Because of bug 998260, during the first call the elements don't have the correct size (e.g. label.getLongWeekdayPixels() is 0), therefore mLongWeekdayTotalPixels is set to the wrong value of 10 and the method will not be able to change it any more when called afterwards.

The patch fixes the flaw in getLongWeekdayTotalPixels() and keeps mLongWeekdayTotalPixels to -1 until the interface returns values different than 0 for label.getLongWeekdayPixels().


Reading a comment by Philipp about another bug, I'm not sure that bug 998260 is reproducible on other platforms than Windows, so I've set the platform on Win7 on this bug, please change it if you can reproduce on others platforms.
Attachment #8436302 - Flags: review?(Mozilla)
Comment on attachment 8436302 [details] [diff] [review]
patch - v1

I could also reproduce the issue on Linux. Since I have no working windows build at the moment, I could only test the patch on linux and there the problem is resolved.

Therefore also changeing the Platform for this bug to "all"
Attachment #8436302 - Flags: review?(Mozilla) → review+
OS: Windows 7 → All
This bug is now in LG 3.3.
Attachment #8436302 - Attachment is obsolete: true
Attachment #8464309 - Flags: review+
Hardware: x86_64 → All
Target Milestone: --- → 3.6
Version: Trunk → Lightning 3.3
Keywords: checkin-needed
Do you think we should backport this in case we do a 3.3.1 release?
(In reply to Philipp Kewisch [:Fallen] from comment #4)
> Do you think we should backport this in case we do a 3.3.1 release?

The horizontal scrollbar allows anyway to see the whole week-view, therefore the bug it's only a bit uncomfortable when the window is small, but nothing is missing.
On the other hand the patch is simple and should be safe, but lately there has been some case that seemed simple and instead caused some problem. Maybe if we could see the code in the repository a bit in advance before the release ...
YOLO, lets do it: https://hg.mozilla.org/releases/comm-esr31/rev/561eaed85279

Leaving open for the remaining checkins.
Target Milestone: 3.6 → 3.3.1
https://hg.mozilla.org/comm-central/rev/17422c1f7444
https://hg.mozilla.org/releases/comm-aurora/rev/47e507c3084e
https://hg.mozilla.org/releases/comm-beta/rev/c54d82e589fb

This patch will not be in 3.4, but given its not a major release and the cycle is long gone, I'm not going to fix it there.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Duplicate of this bug: 1075084
You need to log in before you can comment on or make changes to this bug.