The GUI now tracks when it becomes disconnected from ChessEngine.
If not currently waiting for a move from ChessEngine, it will
automatically reconnect on the next engine move. If a disconnection
occurs while waiting for a move, the player is asked whether they
want to try again or not.
We are currently using the fetch controller's terminate() method to stop
ongoing fetches when the HTMLMediaElement load algorithm is invoked.
This method ultimately causes the fetch response to be a network error,
which we propagate through the HTMLMediaElement's error event. This can
cause websites, such as Steam, to avoid attempting to play any video.
The spec does not actually specify what it means to "stop" or "cancel" a
fetching process. But we should not use terminate() as that is a defined
spec method, and the spec does tend to indicate when that method should
be used (e.g. as it does in XMLHttpRequest).
The HTMLMediaElement will need to stop fetching processes when its load
algorithm is invoked while a fetch is ongoing. We don't have a way to
really stop the process, due to the way it runs on nested deferred task
invocations. So for now, this swaps the fetch callbacks (e.g. to process
a fetch response) with empty callbacks.
This is the first step towards implementing the new "navigable" concept
from the HTML spec.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
The "browsing context container" concept in the HTML spec has been
replaced with "navigable container". Renaming this is the first step of
many towards implementing the new world.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
Now that LengthStyleValue never contains `auto`, IdentifierStyleValue is
the only type that can hold an identifier. This lets us remove a couple
of virtual methods from StyleValue.
I've kept `has_auto()` and `to_identifier()` for convenience, but they
are now simple non-virtual methods.
Previously, whether trying to parse a `<length>` or `<dimension>`, we
would accept `auto` and produce a `LengthStyleValue` from it. This
would fool the `property_accepts_value()` into allowing `auto` where it
does not belong, if the property did accept lengths.
Of the few places in the parser that called `parse_dimension_value()` or
`parse_length()`, none of them were expecting it to accept `auto`, so
this fixes those too. :^)
Currently, `property_accepts_value()` always returns `true` if the
property is a shorthand. (This is a bug, and should actually be fixed
properly at some point...) This means that all identifiers are caught
here, including `auto`, which should be handled by the `flex-basis`
branch instead.
This works currently because `auto` is a LengthStyleValue, but that's
about to change!
This code assumed that `auto` was always stored as a LengthStyleValue,
which will not be true in the next commit. (And was not a safe
assumption to make anyway.)
This is a tiny bit messy because:
- The spec says we should expand this to `flex: <flex-grow> 1 0`
- All major engines expand it to `flex: <flex-grow> 1 0%`
Spec bug: https://github.com/w3c/csswg-drafts/issues/5742
This should not affect boot times on qemu, as that does not use
dynamic transfer delays in its adma code path.
On real hardware this could potentially double the data throughput,
decreasing load times.
While at it, pass the `--3way` option to give the user something to work
with. Otherwise, Git will just prepare the commit metadata and nothing
else. Note that this has a relatively low chance of working, since the
recorded blob hashes aren't known to a freshly imported repository.
This is far from perfect, but let's at least make an attempt at laying
out <svg> when encountering it inside another <svg>.
This makes https://awesomekling.substack.com actually load and render
instead of asserting. :^)
Negative accumulation on the right-hand side of the accumulation bitmap
would wrap around to the left, causing a negative start for certain
lines which resulted in horizontal streaks of lower alpha values.
Prevent this by not writing out of bounds :^)
Fixes#18394
An oval approximated by quadratic bezier curves ended up with 2048 line
segments when rasterized to a bitmap of around 35 by 35 pixels, which
seems a bit much. :^)
By increasing the tolerance by an order of magnitude, that same oval is
now split up into 512 line segments, which is still more than enough for
a high quality render.
