At the same time, simplify CMakeLists magic for libraries that want to
include Swift code in the library. The Lib-less name of the library is
now always the module name for the library with any Swift additions,
extensions, etc. All vfs overlays now live in a common location to make
finding them easier from CMake functions. A new pattern is needed for
the Lib-less modules to re-export their Cxx counterparts.
For both types of elements, `.selectionStart`, `.selectionEnd`,
`.selectionDirection`, `.setSelectionRange()`, `.select()` and the
`select` event are now implemented.
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
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.
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.
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. :^)
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.
`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.
The CRC2D path should be unaffected by the CRC2D transform changing.
To achieve this, we transform the path to compensate whenever the
CRC2D transform is changed.
This thing is essentially a wrapper around an SkPath, although we do
some indirection via a PathImpl class to keep the door open for
alternative rasterizer/path backends in the future.
We also update the 2D canvas code, since that was the only code that
used Painter+DeprecatedPath, and this allows us to just drop that
code instead of temporarily supporting it until the next commit.
