When I run this in the browser console: ``` var linkset = document.createXULElement("linkset"); var link = document.createElementNS("http://www.w3.org/1999/xhtml", "link"); link.setAttribute("rel", "localization"); link.setAttribute("href", "toolkit/main-window/editmenu.ftl"); document.documentElement.appendChild(linkset); linkset.appendChild(link); ``` The link gets created, but `document.l10n` is null and no translation happens. AFAICT initialization is skipped after initial parse in this case since there's no localization link in the markup (https://searchfox.org/mozilla-central/rev/9e7995b3c384945740985107a4de601b27904718/dom/base/nsDocument.cpp#3409), so then we hit a case where we think we're still parsing at https://searchfox.org/mozilla-central/rev/9e7995b3c384945740985107a4de601b27904718/dom/base/nsDocument.cpp#3365-3368. Ideally this would "just work" and strings would get translated right after the link is inserted. Or at least `document.l10n` would initialize and we could translateFragment directly.

Comment on attachment 9008242 [details] Bug 1490457 - Support dynamically inserted localization links when a document didn`t have any links during parse. r=smaug Olli Pettay [:smaug] has approved the revision.

Zibi, I've pushed up a test case. However, it is failing and I'm not sure why. If I do the same thing in the Browser Console: console.log(!document.l10n, "l10n not initialized"); MozXULElement.insertFTLIfNeeded("crashreporter/aboutcrashes.ftl"); console.log(document.querySelector("linkset link"), "link exists"); console.log(document.l10n, "l10n initialized"); All the results look right, but in the test file, at the final document.l10n check it's still null. It's even null if I set a timeout and wait for a second. Any ideas why browser.xul would be different than this test xul file?

(In reply to Brian Grinstead [:bgrins] from comment #4) > All the results look right, but in the test file, at the final document.l10n > check it's still null. It's even null if I set a timeout and wait for a > second. Any ideas why browser.xul would be different than this test xul file? Just figured out if I change the test to run in window.onload instead of DOMContentLoaded then it passes. Maybe `mReadyState == READYSTATE_COMPLETE` isn't true during the DOMContentLoaded event listener in JS?

In the test file, for some reason `document.readyState == "uninitialized"` in the DOMContentLoaded listener which at least explains why we aren't hitting the new condition you added for READYSTATE_COMPLETE. I'd still think we would eventually get l10n to show up once it does become initialized.

Try looks good so far: https://treeherder.mozilla.org/#/jobs?repo=try&revision=267c6a0c64ba2d17b105f928933365c058de7d09

I'd really like to get this landed so I can rebase the findbar work on top of it, so I'm going to push the fix and spin off a follow up bug to add the test.

Pushed by bgrinstead@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ca0a5b2472ac Support dynamically inserted localization links when a document didn`t have any links during parse. r=smaug

Actually, will just mark leave-open while we work on landing the test.

Comment on attachment 9008800 [details] Bug 1490457 - Add test for dynamically inserted localization links after parse;r=zbraniecki Zibi Braniecki [:gandalf][:zibi] has approved the revision.

Pushed by bgrinstead@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5d9bb31b4cf7 Add test for dynamically inserted localization links after parse;r=zbraniecki