Much easier to manage and view diffs this way, rather than one large
single line. This will soon be the only method in this file, so there's
no concern over taking up too much vertical space here.
For replaced elements with percentage width or height, we were treating
them as 0 instead of auto when their containing block had an indefinite
corresponding size.
This produced incorrect layouts in various cases, and although I can't
actually find something about this exact scenario in specs, the new
behavior does match other browsers.
This is an editorial change to the Intl Enumeration API proposal. See:
807b444
Note that this was followed by a normative change to actually ensure the
returned values are canonical:
075a6dc
But the values we return are already canonical.
This cannot be done on the Browser or WebDriver ends, or via the
existing run_javascript() IPC endpoint, as we cannot transfer JS objects
through the IPC boundary (yet), only serialized JSON, so the individual
WebDriver steps around script execution need to run in the WebContent
process.
When mixing calc() and var(), we're forced to delay resolving them until
we're in StyleComputer. Previously we'd just skip over them.
This patch handles calc() in the same pass as attr(). We reparse the
calc() value after var() expansion, and then try to resolve it to a
constant value if possible. If it's not possible, we leave the calc()
where it is, and maybe layout can figure it out later.
Note that I've only implemented resolution to integer and percentage in
this commit. There are more things a calc() could resolve to, and we
should implement those as well.
These will be used when resolving calc() values in StyleComputer.
It's indeed strange that calc() resolves to tokens, but it's how the
engine currently handles those things. There is room for improvement.
Some terminals start with a 0x0 buffer, run the shell, then switch to
a normal buffer size; avoid crashing in this case.
Also downgrade the paging TODO to a FIXME, a slightly broken terminal is
okay if all you're doing is using unimplemented features such as putting
too much text into the terminal.
This doesn't follow the spec to a tee. Our OutOfProcessWebView already
has a bitmap that can be used as the window screenshot. Therefore, we
can bypass the steps that assume we need to access the window's frame
buffer in-flight.
We also don't create an HTMLCanvasElement. We would need a Document in
the WebDriver process to do so. Instead, we can still run the encoding
steps exactly as-is using the screenshot bitmap.
Some endpoints, like /session/{id}/screenshot, will require sending
large data to the client. We won't be able to write all of the data in
one shot, so loop over the data until we've sent it all (or fail).
