STR: - change to get miniday displayed in the today pane - retstart TB Result: - month and year values are set to the dummy values February 5555 instead to the actual month and year. Day, weekday and cw are displayed correctly. moving to another day updates both values correctly. Expected: - the actual monht and year are displayed at startup This is not an issue in TB 52 and not related to the datetimeformatter changes in bug 1229684 (occered with and without the patch). I haven't looked further into the issue, but maybe the rework of the minimonth in bug 472448 has caused this or the missing migration of the remaining occurences of toLoacleFormat() in calendar code.
I can reproduce this issue on trunk only with the 64bit version but not on the 32bit version. With bug 1070491 had been applied a workaround to this issue because an index about the deck that shows the year and weekday get reset during startup without a known (to me) reason.
I am seeing this also on 32bit with a new profile. If you inspect that with DOM Inspector, you can see that the node values for the first and the current month are updated with the correct month/year naming applicable for the current month, but the selected node is the current month's node index minus 2 (at least derived from that sample: other then yesterday, I got today Mar 5555). So the selectedIndex is changed somewhere after the current month's label was updated.
Summary: Miniday shows dummy values for year and month at starttime → Miniday shows dummy values for year (5555) and month at starttime
Created attachment 8895257 [details] [diff] [review] patch-v1 As far as I can see, the difference compared to bug 1070491 is that, now, the selectedIndex of the deck "monthNameContainer" is reset to the integer part of the number: current_month/2 (e.g. for August: 7/2 = 3 that is April), instead of 0 like it was in the other bug. Now the reset happens when TodayPane.setTodayHeader() is called . Following the code I arrive to this line inside "adjustWeekdayLength" method : let clientWidth = document.getAnonymousElementByAttribute(this, "anonid", "mainbox").clientWidth; before that line the selectedIndex is correct and after it changes to the wrong value as mentioned above. If someone has a good idea about the reason of this behaviour we can try a real fix otherwise as a workaround we can initialize twice the miniday (and deleting the workaround for the previous bug). Another possibility is to get rid of the decks in the miniday and make use of simply labels that should be a definitive fix for this kind of issue. Because of a hard disk crash I've lost my ssh keys so at the moment I can't try the patch on the try-server but it shouldn't affect the mozmill tests.  https://dxr.mozilla.org/comm-central/source/calendar/base/content/today-pane.js#36  https://dxr.mozilla.org/comm-central/source/calendar/base/content/calendar-base-view.xml#405
Assignee: nobody → bv1578
Status: NEW → ASSIGNED
Attachment #8895257 - Flags: review?(philipp)
Attachment #8895257 - Flags: review?(philipp) → review+
Attachment #8895257 - Flags: approval-calendar-beta?(philipp)
Pushed by email@example.com: https://hg.mozilla.org/comm-central/rev/62701153a550 Miniday shows dummy values for year (5555) and month at starttime. r=philipp
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Attachment #8895257 - Flags: approval-calendar-beta?(philipp) → approval-calendar-beta+
Beta (TB 56, Calendar 5.8): https://hg.mozilla.org/releases/comm-beta/rev/a64bcaaa03c860887d33b0377e138ce399375185
Target Milestone: 5.9 → 5.8
You need to log in before you can comment on or make changes to this bug.