We were mistakenly trying to append UTF-16 code units to a StringBuilder
via the append(char) API. This patch fixes that by accumulating the
result in a Vector<u16> instead.
This'll be a bit worse for performance, since we're now doing additional
UTF-16 string conversions, but we're going for correctness at this stage
and can worry about performance later.
Because of how we output lines in the loop above, if we leave that loop
when the last line was not the same in both files, then either
`file1_line` or `file2_line` has not been output yet.
`process_remaining()` does not print that line either, since it
immediately reads a new line. So, output the previously-missing line
before we call that. :^)
These are based on the ones in Firefox:
`$(selector, element = document)`:
Equivalent to `element.querySelector(selector)`.
`$$(selector, element = document)`:
Equivalent to `element.querySelectorAll(selector)`.
This holds the return value of the expression that was last entered into
the browser console. If that last expression returned an error of some
kind, `$_` will be `undefined`. This matches the behaviour in Firefox.
This allows us to expose extra functions and properties to the console,
such as `$0`, without them being available to website scripts.
`ConsoleEnvironmentSettingsObject` is basically a stub, since we require
an `EnvironmentSettingsObject` but it has abstract methods.
If the page's URL is changed from within the WebContent process (e.g.
window.location.href is set from JavaScript, or a navigation is started
from WebDriver), we would not store the URL at all within OOPWV. This
prevented actions like reloading from working properly, as the browser
would reload whatever URL was previously entered in the URL box.
Two Blocking modals in the same modal chain which aren't descended
one from the other will block each other's input rendering the chain
noninteractive. This has caused confusion in the past for builders so
this warning makes the behavior explicitly forbidden.
