It occurred to me that we can actually run this unit-test in Node.js environments by making use of the preprocessor to stub out the browser globals there.
Apparently the ESLint rule added in PR 15031 wasn't able to catch all cases that can be converted, which is probably not all that surprising given how some of these call-sites look.
- Use `Element.prepend()` to insert nodes before all other ones in the element, rather than using `firstChild` with `insertBefore`-calls; see https://developer.mozilla.org/en-US/docs/Web/API/Element/prepend
- Fix one *incorrect* `insertBefore` call, in the AnnotationLayer-code.
Initially the patch simply changed that to an `Element.before()`-call, however that broke one of the integration-tests. It turns out that the `index` may try to access a non-existent select-child, which triggers undefined behaviour; note the warning in https://developer.mozilla.org/en-US/docs/Web/API/Node/insertBefore#parameters
Currently this leads to confusing behaviour with `eventBusDispatchToDOM = true` set, since then there's *two* different "localized" events being fired.
See "Case-insensitive language comparisons per RFC 4646"
https://github.com/fabi1cazenave/webL10n/pull/51
Removed the "patch" in compatibility.js and fixed the bug in webL10n,
because the logic belongs to webL10n instead of PDF.js.
The immediate motivation for this patch is that Chrome 40 converts
navigator.language to lower case: https://crbug.com/454331
Based on http://pastebin.mozilla.org/3061694
1. Remove "debug helpers" and use console.log/console.warn directly (top).
2. Remove page load initialization (middle).
3. Remove window._ alias (bottom)
The original diff contained an extra entry
"Adds fallback argument to the getL10nData;",
but this was already implemented in the rebased webL10n, so it's no
longer PDF.js-specific.
