SVG and and CSS border rendering now sits on top of SkPath instead of
the old Gfx::DeprecatedPath.
Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff
in one ref test, I changed that test to not depend on border rendering
for a positive result, since that was incidental.
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.
This new painter is written with a virtual interface from the start,
and we begin with a Skia backend.
This patch adds enough to support our basic 2D HTML canvas usecase.
We should only block the escape key from being sent to the web page if
the CloseWatcherManager actually closed something.
We use the escape key in the Inspector to cancel editing a DOM field.
This unconditional early return broke this feature.
The AppKit Application class is responsible for launching all helper
processes. This had to be moved to a .cpp file because we were unable to
include headers with the Protocol namespace in .mm files, as they would
conflict with the Protocol interface defined by Apple.
Now that this namespace has been renamed to Requests, we can remove this
workaround.
When working on the Inspector's HTML, it's often kind of tricky to debug
when an element is styled / positioned incorrectly. We don't have a way
to inspect the Inspector itself.
This adds a button to the Inspector to export its HTML/CSS/JS contents
to the downloads directory. This allows for more easily testing changes,
especially by opening the exported HTML in another browser's dev tools.
We will ultimately likely remove this button (or make it hidden) by the
time we are production-ready. But it's quite useful for now.
After the refactor to use CSS variables for dark-mode colors in commit
ae25146b89, we had duplicated blocks for
some CSS rules. This patch just unites them into one block.
Improve handling of APNG chunks by avoiding premature termination when
encountering non-fcTL chunks. With this patch, the browser now passes
additional APNG-related tests in the "png/" Web Platform Tests (WPT)
suite.
...if only the scroll offset is updated.
Currently, on any document with a large amount of content, the process
of building a display list is often more expensive than its
rasterization. This is because the amount of work required to build a
display list is proportional to the size of the paintable tree, whereas
rasterization only occurs for the portion visible in the viewport.
This change is the first step toward improving this process by caching
the display list across repaints when neither style nor layout requires
invalidation. This means that repainting while scrolling becomes
significantly less expensive, as we only need to reapply the scroll
offsets to the existing display list.
The performance improvement is especially visible on pages like
https://ziglang.org/documentation/master/ or
https://www.w3.org/TR/css-grid-2/
A new display list item type named PaintScrollBar is introduced. Having
a dedicated type for scroll bars allows the thumb position to be updated
without rebuilding a display list. This was not possible with
FillRectWithRoundedCorners that does not allow to tell whether it
belongs to scroll thumb.
Copy a display list item and apply scroll offset instead of mutating
display list directly.
It's a preparation for upcoming changes where a display list will be
cached across repaints and used multiple times with different scroll
offsets.
This forwards all drag-and-drop events from the UI to the WebContent
process. If the page accepts the events, the UI does not handle them.
Otherwise, we will open the dropped files as file:// URLs.
This forwards all drag-and-drop events from the UI to the WebContent
process. If the page accepts the events, the UI does not handle them.
Otherwise, we will open the dropped files as file:// URLs.
This factory forced callers to make a list of GC-allocated FileAPI::File
objects. This isn't safe - this opens a window for these files to be
garbage collected before the FileList object stores / visits the list.
Instead, only allow creating an empty FileList and incrementally adding
files to that list.
The drag-and-drop processing model allows for users to drag around
either elements within the DOM or objects completely outside the DOM.
This drag event can either end without action (via cancellation or user
input), or in a drop event, where the dragged object is dropped onto
another element within the DOM.
The processing model is rather large. This implements enough of it to
allow the UI process to specifically handle dragging objects outside of
the DOM onto the DOM. For example, dragging an image from the OS file
manager onto a file-upload input element. This does not implement the
ability to drag DOM elements.
We can get away with using the forward declaration of EditEventHandler
in the header file (and avoid ~1k rebuilt files when EditEventHandler is
modified).
There will be an upcoming DragAndDropEventHandler class, so this patch
just sets things up so that the edit and drag-and-drop event handlers
are stored the same way in EventHandler.
Just to sanity check that we can import the library, and that it at
least interprets the generated enumeration values properly, let's
do some simple testing of the swift integration.
When using a configuration without a swift compiler, we need to no-op
the swift annotations. Other, cleverer solutions beyond the has include
all fell flat in the face of the clang modules implementation used by
swift to parse-once use-everywhere each module.
The PageClient for SVGDecodedImageData needs to actually have the
definition of PageClient available in order to inherit from it. This
fixes importing this header from Objective-C or Swift.
The identifier "Protocol" is claimed by Objective-C and Swift for use
by the language's built-in protocol conformance feature, which is
similar to Rust traits or Java interfaces.
Rename LibProtocol -> LibRequests, and its namespace from Protocol to
Requests to accomodate this.