When scripts receive a DataTransferItem from any IDL method, the spec
requires we return the same DataTransferItem for a particular item in
the drag data store. Meaning, we cannot just create these on the fly as
needed.
To do this, we store a list of DataTransferItem on the DataTransfer
object. We will return one of these objects any time one is requested by
a script.
It feels a bit weird to have the DataTransfer object store: the drag
data store, a DataTransferItemList, and a list of DataTransferItem. But
this is how other engines implement this as well. It basically has to be
this way as DataTransferItemList is just a proxy to the DataTransfer -
meaning, DataTransfer is the source of truth for all IDL access.
A DataTransferItem is associated with a DataTransfer, and points to an
item in the drag data store. We don't yet support removing items from
the store, but when we do, we will clear the index stored here to set
the DataTransferItem's mode to "disabled".
The IDL constructor has to take separate steps than a DataTransfer that
is internally constructed. Notably, an IDL-created object has its own
drag data store, and that store is placed in a read-write mode.
Ownership of the drag data store is a bit weird. In a normal drag-and-
drop operation, the DragAndDropEventHandler owns the store. When events
are fired for the operation, the DataTransfer object assigned to those
events are "associated" with the store. We currently represent that with
an Optional<DragDataStore&>.
However, it's also possible to create DataTransfer objects from scripts.
Those objects create their own drag data store. This puts DataTransfer
in a weird situation where it may own a store or just reference one.
Rather than coming up with something like Variant<DDS, DDS&> or using
MaybeOwned<DDS> here, we can get by with just making the store reference
counted.
We don't actually generate any such events ourselves. But Google Lens
will create one with the DataTransfer attribute set to that of any drop
event we send it.
Previously, a crash would occur in the if `CSSPixelFraction` was given a
denominator value less than the resolution of `CSSPixels` (1/64).
We now divide both parts of the ratio by the denominator in this case.
- Expose table from console object
- Add new Table log level
- Create a JS object that represents table rows and columns
- Print table as HTML using WebContentConsoleClient
Prior to funcref, a partial chunk of an invalid module was never needed,
but funcref allows a partially instantiated module to modify imported
tables with references to its own functions, which means we need to keep
the second module alive while that function reference is present within
the imported table.
This was tested by the spectests, but very rarely caught as our GC does
not behave particularly predictably, making it so the offending module
remains in memory just long enough to let the tests pass.
This commit makes it so all function references keep their respective
modules alive.
If the document is disconnected from the navigable by the time a favicon
decode completes successfully, we don't want to show the favicon for
whatever document is now loaded in the navigable.
Fix this by deferring getting the navigable until after the decode has
completed.
When determining the intrinsic cross size contribution of a flex item
with a preferred aspect ratio, we have to account for any min/max
constraints in the main axis.
Capture the incoming reason argument to
transform_stream_default_source_cancel_algorithm() on the
on_fulfilled_callback() of WebIDL::react_to_promise() on step 7.
Instead of CSSColorValue holding a Gfx::Color, make it an abstract class
with subclasses for each different color function, to match the Typed-OM
spec. This means moving the color calculations from the parsing code to
the `to_color()` method on the style value.
This lets us have calc() inside a color function, instead of having to
fully resolve the color at parse time. The canvas fillStyle tests have
been updated to reflect this.
The other test change is Screenshot/css-color-functions.html: previously
we produced slightly different colors for an alpha of 0.5 and one of
50%, and this incorrect behavior was baked into the test. So now it's
more correct. :^)
"Parse a style value for <foo>", where we don't care if it's a literal
<foo> or a calculated one, is a really common thing that we previously
didn't have methods for.
A couple of methods we had have been extended to parse calc(), and the
others have been filled in.
The method for parsing the `flex` property's value is renamed
`parse_flex_shorthand_value()` as it conflicted.
For simplicity in user code, the `parse_foo_value()` methods should
parse anything that is a `<foo>`. In these cases, that means a
number/integer or calculation that resolves to them.
These uses in parse_css_value_for_properties() specifically only want a
literal IntegerStyleValue/NumberStyleValue, as calc-parsing is done
elsewhere. So, do the parsing for them locally.
Parsing a `Gfx::Color` no longer makes sense, as CSS has many ways of
defining a color, often in a dynamic way where the color value isn't
known until later. This is a small preparatory change before a much
larger color rewrite.
Soon, CSSColorValue will be an abstract class, and we'll instead create
a CSSRGB, CSSHSL, or other specific color type from the Typed-OM spec.
However, it's still useful to have an easy "just give me a style value
for this color" method. So change the name to distinguish this from the
usual StyleValue::create() methods.
CSS-Typed-OM has the following hierarchy:
CSSStyleValue
- CSSNumericValue
- CSSUnitValue
- CSSMathValue
- ...various math functions...
Somewhat unintuitively, numbers are also stored using CSSUnitValue with
`unit = "number"`.
There are no distinct classes for LengthStyleValue, etc in the spec, but
they're convenient for us, so they are implemented as subclasses of
CSSUnitValue, at least for now.
Always assuming unpremultiplied color data only worked for PNGs (which
are specced as unpremultiplied) and bitmaps with alpha set to 100%.
Properly propagate the Gfx::AlphaType of a bitmap to Skia.
The reference tests were updated to reflect this change, but visually
it's practically impossible to see the difference. A new test was added
to clearly expose this issue.
Fixes#1104
Before this change, we were passing CGColorSpaceCreateDeviceRGB() to
CGImageCreate(), causing the system to assume that the image data is
in a device-specific RGB space without any color profile adjustments.
If your monitor is more vibrant than the assumed profile (for example,
a wide-gamut display), colors may appear over-saturated as there's no
correction applied for how the display actually renders those colors.
We now pass CGColorSpaceCreateWithName(kCGColorSpaceSRGB) instead,
which makes colors look the same in Ladybird as in other browsers. :^)
Instead, it could be applied directly as a clip path in Skia painter.
As a side bonus, we get rid of some DeprecatedPath and
AntiAliasingPainter usage.
We don't have to invalidate style for the entire document when a style
sheet changes inside of a shadow root.
To make this possible, StyleSheetList now keeps track of which
Document-or-ShadowRoot it corresponds to, instead of just tracking the
containing Document.
This avoids a lot of style recomputation on pages with lots of shadow
DOM content (like GitHub).
Before this change, we would go through every known pseudo element and
compute style for it whenever recomputing the style of an element.
This led to disastrous performance on pages with selectors like
`::selection` or `::placeholder`, as they'd effectively match every
single element and thus we'd compute multiple additional styles for
every element in the DOM.
The fix is simple: only recompute `before` and `after` pseudo element
styles, since those are the only two pseudo elements that generate
*new* nodes -- other pseudo elements refer to (possibly) existing
nodes or concepts within the DOM (or internal shadow DOM).
This makes style updates take ~40ms on our GitHub repo instead of
~220ms. It's still slower than it should be, but a huge improvement.
This gives us free devirtualization of some hot calls inside the
bytecode interpreter. Most notably the did_trap() checks.
Modest performance improvement on the https://figma.com/ landing page.
`BrowsingContext::m_parent` has been removed from the spec,
and previously `m_parent` was always null.
`BrowsingContext::is_top_level` was already always returning
true before because of that, and the updated spec algorithm
causes assertions to fail.
This fixes the following example:
```html
<a href="about:blank" target="test">a
<iframe name="test">
```
clicking the link twice no longer causes it to open in a new tab.
