From the CSS token side, we already have these in FlyString form. From
the generated code side, we can easily return FlyStrings instead of
StringViews. So, let's do that, and save some work converting back and
forth.
There was a warning for the Optional initializer having no effect, but
removing the initializer caused the call to add a track to the HashMap
to complain. A constructor looks a little nicer here anyway.
Most users will only care about the total file duration, and shouldn't
be required to determine the file duration from multiple track
durations. To facilitate that, add a total_duration() function that
returns the demuxer's duration not associated to any particular track.
Some properties like `justify-items`, `grid`, or `display` do affect
layout, but their used values can be obtained without performing a
layout calculation.
This change introduces a new helper,
`property_needs_layout_for_getcomputedstyle()`, specifically for use by
`CSSStyleProperties::property()`. It returns true only for properties
such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where
an up-to-date layout is required to return the correct used value.
This fixes an issue where text decorations (e.g. underlines) of text
split across multiple fragments would have unintended 1px gaps.
Gains us 2 WPT passes (imported)
By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now
in sync - the AppKit UI was previously missing some actions.
Further, this inadvertently fixes bugs around applying debug settings to
new web views, especially across site-isolated processes. We were
previously not applying settings appropriately; this now "just works" in
the LibWebView infra.
This migrates all duplicated context menus from the UIs to LibWebView.
The context menu actions are now largely handled directly in LibWebView,
with some UI-specific callbacks added to display e.g. confirmation
dialogs.
Actions that only ever apply to a specific web view are stored on the
ViewImplementation itself. Actions that need to be dynamically applied
to the active web view are stored on the Application.
We currently duplicate a lot of code to handle application/context menus
and actions. The goal here is to hold the data for the menus and actions
in LibWebView. Each UI will then be able to generate menus from the data
on-the-fly.
The structures added here are meant to support generic and checkable
actions, action groups, submenus, etc.
The result is currently only used as a StringView, but a future commit
will place the result in Web::Clipboard::SystemClipboardRepresentation,
which requires a ByteString (there's no UTF-8 clipboard requirement).
As noted, the chunk of this method that deals with animations could do
with some helpers on AbstractElement, but I'm leaving that until it's
clearer how animations and pseudo-elements should interact.
