Bugzilla

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #3)
> ```js
> let frag = document.getElementByid("myFrag");
> await document.l10n.translateFragment(frag);
> let { size, position } = getSize(frag);
> paint();
> ```

OK, but as I said in the menus bug, that's really not how things work; there is no JS-accessible "paint" API, or a show/hide window API, AFAIK. We just get JS that runs when the DOM loads, and graphics/XUL/DOM code takes care of painting pretty much independently. My point is, when we built a tool to do async l10n, did we build hooks into window (and menu and other things that are widget-level windows) creation/painting that can be used to block painting / showing windows? I'm assuming this was considered at the design stage, instead of basically telling people "here's the exciting new thing you should use" and then when we run into these issues go "sorry, that's up to you to create and fix".

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #3)
> ```js
> let frag = document.getElementByid("myFrag");
> await document.l10n.translateFragment(frag);
> let { size, position } = getSize(frag);
> paint();
> ```

OK, but as I said in the menus bug, that's really not how things work; there is no JS-accessible "paint" API, or a show/hide window API, AFAIK. We just get JS that runs when the DOM loads, and graphics/XUL/DOM code takes care of painting pretty much independently. My point is, when we built a tool to do async l10n, did we build hooks into window (and menu and other things that are widget-level windows) creation/painting that can be used to block painting / showing windows?