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).
This PR adds resize ability to PixelPaint as per issue 11862.
The previous behaviour was to always rescale the canvas when
resizing an image. This adds a checkbox to toggle between
rescaling, and resizing which blits the existing canvas to
the top left of the new, resized canvas.
As part of this, a new ScalingMode is added to
LibGfx - None.
This parses conic-gradient()s while also attempting to share the bulk
of the parsing code with linear-gradient()s. This is done by extracting
the <color-stop-list> parsing to a "fill in the blacks" generic
function. This is a little awkward but cuts down on a lot of copy
pasting of code.
This parses <position> according to the following grammer:
<position> = [
[ left | center | right ] || [ top | center | bottom ]
|
[ left | center | right | <length-percentage> ]
[ top | center | bottom | <length-percentage> ]?
|
[ [ left | right ] <length-percentage> ] &&
[ [ top | bottom ] <length-percentage> ]
]
The code is a little hairy and simply tries each alternative in turn,
manually checking the possible orders. There may be a better way to
represent this.
This class represents a <position> and handles resolving it to a
Gfx::FloatPoint relative to some rectangle.
It can handle all forms of <position>:
- Two presets:
left center
- A preset + a length percentage:
10% bottom
- Or relative to some edges:
right 20% bottom 30px
This commit adds a simple style value (which is an abstract image)
to represent conic-gradient()s.
This commit also starts to factor out some reusable parts of the
linear-gradient() style value for other gradient types.
LibWeb's Window object will need to know the OS-level position and size
of the GUI::Window for e.g. screenX, screenY, outerWidth, outerHeight.
It will also need to know about changes to that data.
These were no longer being picked up after some recent changes. Since
port builds happen in subshells nowadays, we can get rid of the export /
unset combo anyway.
This fixes ScummVM crashing on startup, caused by `-fvisibility` not
being set.
This was an oversight from when I converted PendingResponse and various
other classes from being ref-counted to GC-allocated last minute - no
one takes care to keep all of them alive. Some are on the stack, and
some might be captured in another PendingResponse's JS::SafeFunction,
but ultimately, we need a better solution.
Since a PendingResponse is *always* the result of someone having created
a Request, let's just let that keep a list of each PendingResponse that
has been created for it, and visit them until they are resolved. After
that, they can be GC'd with no complaints.
