Support for constructing a Value from a UnixDateTime was added in commit
effcd080ca.
That constructor just stores the value as the number of milliseconds
since epoch. There's no way for outside users to know this, so this adds
a helper to retrieve the value as a UnixDateTime and let SQL::Value be
the source of truth for how the value is encoded/decoded.
The architecture of SQLServer is currently such that it sends results
over IPC one row at a time. After the rows are exhausted, it sends a
completion IPC. However, it does not wait for the client to finish
processing a row before sending another row or the completion signal.
This can result in clients hanging if the completion comes in while a
row is being processed. At least in the case of WebView::Database, the
result is that the completion signal is dropped, and the browser then
hangs forever waiting for that signal (after it finishes processing the
row).
This patch makes SQLServer asynchronously wait for the client to tell it
that the row has been processed and the next row (or completion) may be
sent. We repurpose the `m_ongoing_executions` in SQLStatement for this
purpose (this member was oddly being written to, but otherwise unused).
A certain PDF was drawing some text used `9 0 0 9 474.54 700.6801 Tm`
to set the text matrix to a matrix that scaled by 9 in one text object.
Then, after ending that text object, it had the following new text
object which contained nothing that invalidated the text matrix:
```
BT
/F1 7 Tf
/DeviceRGB CS
0 0 0 SC
10 TL
86.37849 21.908 Td
(Authorized licensed use limited to: ...) Tj
ET
```
`BT` did reset it as required, but since we didn't mark the matrix
as dirty, we never recomputed it and drew the additional text scaled
up 9x.
Until now, we had implemented flex container sizing by awkwardly doing
exactly what the spec said (basically having FFC size the container)
despite that not really making sense in the big picture. (Parent
formatting contexts should be responsible for sizing and placing their
children)
This patch moves us away from the Flexbox spec text a little bit, by
removing the logic for sizing the flex container in FFC, and instead
making sure that all formatting contexts can set both width and height
of flex container children.
This required changes in BFC and IFC, but it's actually quite simple!
Width was already not a problem, and it turns out height isn't either,
since the automatic height of a flex container is max-content.
With this in mind, we can simply determine the height of flex containers
before transferring control to FFC, and everything flows nicely.
With this change, we can remove all the virtuals and FFC logic for
negotiating container size with the parent formatting context.
We also don't need the "available space for flex container" stuff
anymore either, so that's gone as well.
There are some minor diffs in layout test results from this, but the
new results actually match other browsers more closely, so that's fine.
This should make flex layout, and indeed layout in general, easier to
understand, since this was the main weird special case outside of
BFC/IFC where a formatting context delegates work to its parent instead
of the other way around. :^)
- Register the widget
- Register property getters and setters
- Rename getters and setters to match the property names, as required by
the GML compiler. The names min/max/value are chosen to match SpinBox.
- Prevent a crash when the minimum is less than the maximum (which can
happen while editing the GML).
An image mask is a 1-bit-per-pixel bitmap that's black where the
current color should be painted, and white where it should be
transparent (think: like ink).
load_image() already converts images like this into 8-bit-per-pixel
images that have 0xff, 0xff, 0xff in rgb for opaque (originally 0 bit)
pixels and 0, 0, 0 in rgb for transparent pixels.
So we just move copy the image mask's image data into the alpha
channel and replace rgb with the current color, and then draw
it like a regular bitmap.
frame() still returns a regular RGB Bitmap (now lazily converted
from internal CMYK data), but JPEGImageDecoderPlugin now also
implements cmyk_frame().
This is a simple container for 2d CMYK data.
This is a new class instead of a new format in Bitmap because:
* Almost all clients of Bitmap will want to deal with RGB data
* It keeps the ARGB32 typedef working
* Bitmap already does a lot of things
The idea is that a few select places will be able to use
CMYKBitmap and a color profile to do a better CMYK -> RGB conversion
than an image decoder could do, and then store the result in a Bitmap
for later display then.
CMYKBitmap misses some of Bitmap's features, such as shared
memory support, high-dpi scaling capability, etc.
Many sites load application/json and application/ld+json
content with script elements, so this debug line shows
up on a lot of sites and is not informative.
On platinenmacher.tech there is a document without a window. During
size attribute parsing the window pointer is dereferenced which
causes a crash. This checks for the window to be actually there
before dereferencing.
As the spec points out:
> Note that a pair of keywords can be reordered while a combination of
> keyword and length or percentage cannot. So center left is valid while
> 50% left is not.
This was a bug in our implementation of alternative 2 of css-values-3,
resulting in the following CSS failing to be parsed:
`background-position: center right;`
This commit fixes the issue as part of an update of the parsing to
css-values-4. As far as I can tell, the grammar is equivalent - but
simpler to implement due to the lack of optional values.
The fix for this issue is also as part of alternative 2 parsing in the
new grammar.
Progress towards: #22401
Instead of serializing two calc() values to String and then comparing
those strings, we can now compare calc() values by actually traversing
their internal CalculationNode tree.
This makes style recomputation faster on pages with lots of calc()
values since it's now much cheaper to check whether a property with
some calc() value actually changed.
Previously, these were clipped by the RecordingPainter, which used the
path's bounding box (which in this case is zero width or height). The
fix is to expand the bounding box by the stroke width.
Fixes#22661
Note: This is unrelated to any recent LibGfx changes :^)
Some apps seem to generate malformed images that are accepted
by most readers. We now only throw if malformed data would lead to
a write outside the chunky buffer.
Before this change, we used the wrong insertion point for flex items
in reverse layouts with `justify-content: normal`. This caused flex
items to overflow the flex containers "backwards" from the start edge.
This moves us a bit toward correctly representing two separate concepts
from the spec: lines and tracks. Lines divide the grid into tracks, so
there should always be a line concluding the last track.
Instead of assuming that the first font in the cascade font list will
have a glyph for space, we need to find it in the list taking into
account unicode ranges.
When the WebContent process has painted to its shared bitmaps, it sends
a synchronous IPC to the browser process to let the chrome paint. It is
synchronous to ensure the WC process doesn't paint onto the backing
bitmap again while it is being displayed.
However, this can cause a crash at exit if the browser process quits
while the WC process is waiting for a response to this IPC.
This patch makes the painting logic asynchronous by letting the browser
process broadcast when it has finished handling the paint IPC. The WC
process will not paint anything again until it receives that message. If
it had tried to repaint while waiting for that message, that paint will
be deferred until it arrives.
Some tags have a default value, we should return this value in
Metadata's getters when no value has been read from the input file.
Note that we don't support default values for tags with a count bigger
than one.
ExifOrientedBitmap was implemented before the introduction of the TIFF
decoder. So we had to provide a definition of the Orientation enum. Now
that we have a TIFF implementation that comes with some enum
definitions, we should prefer this source.
Process separation is a great way to prevent malicious users from
getting the GUI down with image files that make one of our decoder
crash.
It also makes life easier when developing image decoders.
