The grammar which we implemented did not match the spec, resulting in us
rejecting background positions which contained 'center' position
keywords.
Fixes: #22401
Considering an operation like the following:
document.cookie = "cookie=value";
const value = document.cookie;
If the IPC for the cookie setter is asynchronous, the getter can execute
while the browser/SQLServer processes are still handling the setter.
This is often seen when hammering the document with cookie requests.
LibSQL supports serializing time stamps as of commit
effcd080ca.
However, that commit serializes the timestamps as milliseconds, whereas
the CookieJar was serializing them as seconds. In retrospect, these
should have been updated in unison, along with the SQL heap version (as
this is a serialization change that affects the file format). So this
patch also updates the version, as this is not a backwards compatible
change.
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.
This really only implements a heuristic, assuming that HTTP/1.0 servers
cannot handle having multiple active connections; this assumption has
lots of false positives, but ultimately HTTP/1.0 is an out-of-date HTTP
version and people using it should just switch to a newer standard
anyway.
Specifically, python's "SimpleHTTPRequestHandler" utilises a
single-threaded HTTP/1.0 server, which means no keepalive and more
importantly, hangs and races with more than a single connection present.
This commit makes it so we serialise all requests to servers that are
known to serve only a single request per connection (aka HTTP/1.0 with
our setup, as we unconditionally request keepalive)
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.
For every issue string, json['issues'][issue_string] contains a list
of (page, count_of_issue_on_this_page) tuples.
To get the total number the issue appears in the current document,
we need to add up all the count_of_issue_on_this_page, not multiply the
page number with count_of_issue_on_this_page and add those (－‸ლ)
The newer version installs a specific version of octokit, since the
latest version no longer supports the ruby installation in github
actions vms. This should resolve the CI issues.
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 :^)
