Closed
Bug 1196459
Opened 9 years ago
Closed 9 years ago
document.l10n is not synchronously available
Categories
(Firefox OS Graveyard :: Gaia::L10n, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: zbraniecki, Unassigned)
Details
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.
Comment 2•9 years ago
|
||
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.
Flags: needinfo?(stas)
Reporter | ||
Comment 3•9 years ago
|
||
(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 :)
Comment 4•9 years ago
|
||
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?
Flags: needinfo?(gandalf)
Reporter | ||
Comment 5•9 years ago
|
||
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.
Flags: needinfo?(gandalf)
Reporter | ||
Comment 6•9 years ago
|
||
Landed
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•