I've run into a snag with the dom l10n api. Screenshots does this thing where it loads an empty document, then separately parses a bunch of html with DOMParser and injects that into the empty document:
I have no idea why screenshots works this way (I asked at https://bugzilla.mozilla.org/show_bug.cgi?id=1585588#c6 but never got an answer). In any case, rewriting it appears to me to be a big change that I'm not really equipped to do right now (and I would be reluctant to start without understanding why screenshots was written this way in the first place).
The html that gets parsed/injected is defined here:
In the patch on phabricator, this html includes a
<link rel="localization" ...> element that refers to
screenshots.ftl. In response to review feedback, I tried to update this so that strings in
screenshots.ftl reference terms defined in separate ftl files (
browser/branding/branding.ftl) and then add additional
<link> elements from onboardingHtml to load those files. This is where the bad interaction with the dom l10n api starts.
I'm a little shaky on exactly what's happening but it appears to me that when the parsed html is being adopted,
Document::LocalizationLinkAdded() is called once for each
<link> element. However, since the actual document is already loaded and we're just adopting new content, we end up here on the first
On the second and third
<link>s we take this branch:
But note that the document translation takes place after the first
<link>, so we don't have all the strings and terms available at that time.
I'm not sure what the right fix is here. It looks like there's some support in Document for batching up resource ids (
Document::OnL10nResourceContainerParsed()), but I don't know the platform bits well enough to know if its practical to invoke that path when adopting an entirely new
<head>. Mossop, I think you were the original author of this api, any thoughts?
Also, Jared, can you shine any light on why screenshots works this way in the first place?