Closed Bug 806231 Opened 12 years ago Closed 11 years ago

Startup crash on windows desktop due to %e date format specifier


(Firefox OS Graveyard :: Gaia, defect)

Windows 7
Not set



blocking-basecamp -


(Reporter: jdm, Assigned: jdm)


(Whiteboard: [b2g-desktop-builds])


(2 files)

lockscreen.js passes in %e for the date format, but Windows' strftime doesn't recognize this and crashes.
As does statusbar.js.
This allows the desktop builds to start for me.
Assignee: nobody → josh
Attachment #675982 - Flags: review?(kaze)
I found an additional replacement (in apps/homescreen/js/landing.js), but even with this additional change, B2G Desktop still crashes for me on startup.
Comment on attachment 675982 [details] [diff] [review]
Change all %e to %d

Josh, your patch makes sense but %e is not strictly equivalent to %d: for tomorrow’s date (2012-11-01), '%e' gives '1' whereas '%d' gives '01'.

As these date formatters should never be used without the `mozL10n.DateTimeFormat' object provided by the shared `l10n_date.js' library, I think we should:
 • handle this '%e' question in `l10n_date.js';
 • fix the Calendar app to use localized string formats — or simply use %d instead of %e in this app until James internationalizes the date formats in Calendar.
Attachment #675982 - Flags: review?(kaze) → review-
blocking-basecamp: --- → ?
Not blocking-basecamp on desktop bugs.  Ben has an action to figure out how to track these to support the developer use-case.
blocking-basecamp: ? → -
Whiteboard: [b2g-desktop-builds]
Mike: Andrew blocked bug 795484 on the desktop crasher that this purports to fix, and I would expect the two bugs to have similar blocking statuses.
Myk, if you flip and apply your patch, does B2G start without crashing?
Blocks: 795484
(In reply to Josh Matthews [:jdm] from comment #8)
> Myk, if you flip
> and apply
> your patch, does B2G start without crashing?

Yes!  However, it also starts without crashing if I flip that pref and *don't* apply my patch, so this bug doesn't affect startup crashes one way or the other in my testing.
No longer blocks: 795484
Did we ever figure out the best way forward here?
I don't think this is a problem anymore, because B2G no longer crashes on Date.toLocaleFormat('%e').

Also, there are no longer any instances of Date.toLocaleFormat('%e') in Gaia.  Gaia does still use %e extensively, but only via navigator.mozL10n.DateTimeFormat.localeFormat() from l10n_date.js, which does its own replacement, substituting Date.getDate().
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.