The way we initialize l20n.js makes document.l10n not available synchronously after loading when document.readyState is loading. In case of Settings app, startup.js is loaded synchronously so l20n.js has to be as well. Then startup.js would like to set document.l10n.ready() but it is not available. It seems that we should decouple initialization of Service/View from construction.
Stas, what do you think?
Interesting! Looking at https://github.com/l20n/l20n.js/blob/944ade52a64326783d539d9b77a13dd0abfac23a/src/bindings/html/service.js#L17-L19 it seems that we could create document.l10n without having to wait for DOMContentLoaded. We only need that for getMeta and then, for document.l10n.languages = navigator.languages. Can this wait another day or two? I think this is related to the NGA split which I've been working on.
(In reply to Staś Małolepszy :stas from comment #2) > Can this wait another day or two? I think this is related to the NGA split > which I've been working on. Sure! Glad to hear you're on it :)
Actually, I won't be changing this. And I'm not sure how to solve this. Zibi, do you have some ideas? I remember that at some point we agreed that l20n.js needs to be deferred and that it's on developers to understand this. Do you want to change that assumption? Can we better understand why Settings doesn't defer l20n.js?
Yeah, I believe I want to change this assumption and I'm ok working on a patch for that. The rationale is two fold: 1) l20n.js is supposed to act as a mock. It's fully async now, so the only thing that the DOM API needs to provide is document.l10n collection available. It can initialize later, but should be available immediately 2) Settings need it because they don't defer bootstrap, and the assumption that all bootstrap JS will always be deferred is a weak one.