Closed Bug 1030334 Opened 10 years ago Closed 10 years ago

Initialize MO as early as l10n.js loads

Categories

(Firefox OS Graveyard :: Gaia::L10n, defect, P2)

x86
All
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: zbraniecki, Assigned: zbraniecki)

References

()

Details

Attachments

(4 files)

With bug 992473 landed, we now have MO for Node l10n. But with current code, we initialize MO only after we loaded the resources, which does not cover nodes injected into DOM at runtime, before we have the resources. That's visible in bug 1030094. We should fix it by initializing MO earlier and collecting nodes injected before resources are available and then translating them as soon as possible.
Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Priority: -- → P2
Attached file pull request (deleted) —
Comment on attachment 8459245 [details] pull request It seems to be fairly trivial, unless I missed something. I'll run perf tests because initializing MO earlier might cost sth, but except of that it seems pretty straightforward and it also covers DOM operations during language switch... :) Stas, what do you think?
Attachment #8459245 - Flags: feedback?(stas)
(In reply to Zibi Braniecki [:gandalf] from comment #0) > But with current code, we initialize MO only after we loaded the resources, > which does not cover nodes injected into DOM at runtime, before we have the > resources. I think I need a quick memory refresher here. If nodes are added at runtime before we have the resources, shouldn't they be localized by the onReady's translateDocument? I was also hoping we could remove this very translateDocument call in favor of a MO which is registered very early on. In the patch you left translateDocument and you start observing when document becomes interactive. Why not register it even earlier?
(In reply to Staś Małolepszy :stas from comment #3) > I think I need a quick memory refresher here. If nodes are added at runtime > before we have the resources, shouldn't they be localized by the onReady's > translateDocument? Yes In non-default locale, that's what happens. But in pre-translated case, we do not do the initial translation. > I was also hoping we could remove this very translateDocument call in favor > of a MO which is registered very early on. In the patch you left > translateDocument and you start observing when document becomes interactive. > Why not register it even earlier? That's my ultimate goal as well. I just believe that taking smaller steps is safer when we deal with such a racy code. This patch only introduces coverage for cases we do not cover at all right now (and thus, we use translateFragment there). Because l10n.js is deferred in most apps, we still need translateDocument. I'd like to soon experiment with initializing it without defer and relying on parser feeding MO (and in result, removing the call to translateDocument), but I'm not sure about performance implications. Overall, it seems complex enough (we will still need take into account scenarios in which l10n.js gets loaded too late for MO to localize nodes from parser) that I'd prefer not to cover it in this patch.
Among others, I expect that it may be the cause of bug 1037637.
Comment on attachment 8459245 [details] pull request No significant perf/mem difference on Settings. Tests are green
Attachment #8459245 - Flags: feedback?(stas) → review?(stas)
Comment on attachment 8459245 [details] pull request r=me, with the comments below. I have to admit that our startup logic is hard to read and understand. I actually started working on a similar patch which simplifies the initialization step greatly. I'll attach it shortly to get your feedback. From the patch: + var pendingEntities = null; Please call this pendingElements. + waitFor('interactive', function() { + nodeObserver = new MutationObserver(onMutations.bind(navigator.mozL10n)); + nodeObserver.observe(document, moConfig); + }); The way this block is placed, it will not be executed in the dataset.noComplete edge-case in neterror. + if (pendingEntities) { + for (var i in pendingEntities) { + translateElement.call(this, pendingEntities[i]); + } + pendingEntities = null; } Please use a more idiomatic way to iterate over the elements of the array, e.g. /* jshint boss:true */ for (var i = 0, element; element = pendingElements[i]; i++) { As we've already seen with Cost Control, some apps extend standard objects' prototypes with custom methods even if they shouldn't.
Attachment #8459245 - Flags: review?(stas) → review+
Pull request https://github.com/mozilla-b2g/gaia/pull/22038 TBPL: https://tbpl.mozilla.org/?rev=da6c1c6caa2e&tree=Gaia-Try Gandalf, here's a slightly modified patch. The second commit on my branch is virtually the same as yours. The first one gets rid of excessive setTimeouts. I'll test the perf and report back here.
Attachment #8460265 - Flags: review?(gandalf)
Comment on attachment 8460265 [details] [diff] [review] Similar patch, with more clean-up Review of attachment 8460265 [details] [diff] [review]: ----------------------------------------------------------------- The patch has good perf numbers: app-visually-complete is 20ms later than on master for default locale and 60ms sooner for non-default ones. With one more change described below, the default-locale diff goes down to 10ms. I'll post full numbers in an hour, off to a meeting now. ::: shared/js/l10n.js @@ +1397,2 @@ > } > + initResources.call(navigator.mozL10n); Putting this in a setTimeout improves the performance of the default-locale case, bringing it on the par with master.
moz-app-visually-complete measurements for the SMS app (milliseconds): default locale non-default locale --------------------------------------------------------------------- master 873 1008 gandalf's patch 903 1029 stas' patch 920 1003 stas' patch with setTimeout(initResources) 910 966
(In reply to Staś Małolepszy :stas from comment #9) > Putting this in a setTimeout improves the performance of the default-locale > case, bringing it on the par with master. s/master/your patch/
No significant differences apart from a slight speedup in Settings. Some apps returned test failures (represented by a — in the results).
A slight speedup in Calendar. I'm surprised speedups in Email and FM are not significant.
Comment on attachment 8460265 [details] [diff] [review] Similar patch, with more clean-up Review of attachment 8460265 [details] [diff] [review]: ----------------------------------------------------------------- Let's land this. It simplified the code and seem to work well according to my tests. Please, monitor the datazilla carefully, especially for regressions in moz-app-visually-complete
Attachment #8460265 - Flags: review?(gandalf) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: