Previously, only DOM nodes with `is_editable()` allowed selection via
the mouse. This had the unwanted consequence, that read-only
input/textarea elements did not allow selection.
Now, `EventHandler::handle_mousedown()` asks the node's non-shadow
parent element over the new virtual method `is_child_node_selectable()`,
if selection of the node is allowed.
This method is overridden for `HTMLButtonElement` and
`HTMLInputElement`, to disallow selection of buttons and placeholders.
Fixes#579
We were incorrectly looking at the CSS computed values for width and
height to determine the natural size of <svg> root elements.
This meant that elements where the attribute and computed value were
different values would end up with incorrect natural size.
The spec requires that "multipart/form-data" Content-Type headers also
include a boundary directive. This allows the content server to validate
the submitted form data.
Google Lens, for example, rejects forms missing this directive.
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.
