This required changing the load_sync API to take a LoadRequest instead
of just a URL. Since HTMLScriptElement was the only (non-test) user of
this API, it didn't seem useful to instead add an overload of load_sync
for this.
As defined by the specification (and used by the website i am testing):
interface mixin CanvasDrawPath {
undefined fill(optional CanvasFillRule fillRule = "nonzero");
}
Previously we didn't check if we could insert the element in the
adjusted insertion location's parent.
Also makes the return type NonnullRefPtr, as that's what element is.
This is because it includes the initial node that the function was
called on, which makes it "inclusive" as according to the spec.
This is important as there are non-inclusive variants, particularly
used in the node mutation algorithms.
Also updates the "inserted_into" function as per the previous commit.
Changes the FIXME, as according to the spec there is no notification
system to be notified of things such as the node becoming connected.
Instead, "becomes connected" means when the insertion steps are run,
the element is now connected when it previously wasn't.
https://html.spec.whatwg.org/multipage/infrastructure.html#becomes-connected
This is done in this PR because the insertion steps are run when the
start tag is inserted. This made it try to prepare the script too early
for inline scripts.
The order of operations in the HTML document parser ensures that
the parser document is set before the insertion steps are run.
This particularly affects the insertion steps and the removed steps.
The insertion steps no longer take into the parent that the node
was inserted to, as per the spec. Due to this, I have renamed the
function from "inserted_into" to simply "inserted". None of the
users of the insertion steps was using it anyway.
The removed steps now take a pointer to the old parent instead of
a reference. This is because it is optional according to the spec
and old parent is null when running the removal steps for the
descendants of a node that just got removed.
This commit does not affect HTMLScriptElement as there is a bit
more to that, which is better suited for a separate commit.
Also adds in the adopted steps as they will be used later.
The HTML <label> element is special in that it may be associated with
some other <input> element. When the label element is clicked, the input
element should be activated.
To achieve this, a LableableNode base class is introduced to provide an
interface for "labelable" elements to handle mouse events on their
associated labels. This not only allows clicking the label to activate
the input, but dragging the mouse from the label to the input (and vice-
versa) while the mouse is clicked will also active the label.
As of this commit, this infrastructure is not hooked up to any elements.
A FrameHostElement is an HTML element (<frame> or <iframe>) that may
have a content frame that participates in the frame tree.
This basically just moves code from <iframe> to a separate base class
so we can share it with <frame> once we implement <frame>.
The previous names (RGBA32 and RGB32) were misleading since that's not
the actual byte order in memory. The new names reflect exactly how the
color values get laid out in bitmap data.
There's a bit more nuance to how this should really work, but let's at
least make sure we execute <script> elements if you insert them into
the document.
This was misleading. The spec just wants us to check a string matches
a string in the JavaScript MIME type essence list. It doesn't want us
to parse the string as a MIME type to then use its essence for the
check.
Renames "mime_type" to "string" to make this less misleading.
This is basically just for consistency, it's quite strange to see
multiple AK container types next to each other, some with and some
without the namespace prefix - we're 'using AK::Foo;' a lot and should
leverage that. :^)
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
Text <input> fields will now generate a basic shadow DOM and attach it
to the input element.
The shadow DOM contains a <div> with some inline style, and an always-
editable text node inside it. Accessing the "value" attribute on such
an input element will get/set the value from that text node.
This is really cool, although not super stable since HTML editing is
not super stable. But it's a start! :^)
The approach of attaching sub-widgets to the web view widget was only
ever going to work in single-process mode, and that's not what we're
about anymore, so let's just get rid of WidgetBox so we don't have the
dead-end architecture hanging over us.
The next step here is to re-implement <input type=text> using LibWeb
primitives.
We'll want to remove the LibGUI dependency from the WebContent process.
This is the first basic step of removing unnecessary LibGUI includes
and swapping out GUI::Painter for Gfx::Painter.
Document and HTMLElement now inherit from HTML::GlobalEventHandlers
which allows them to support "onfoo" event handler attributes.
These are assignable both via IDL attributes and content attributes.
Event listeners constructed this way get a special "attribute" flag
on them so we know which one to replace if you reassign them.
This also allows them to coexist with EventTarget.addEventListener().
This is all a bit sloppy, but it works decently for a first cut.
The Window object should also inherit GlobalEventHandlers, but since
we don't generate it from IDL, I haven't taken that step here.
Also this would be a lot nicer if we supported IDL mixins.
This is a workaround until we can implement a proper <input type=text>
in terms of LibWeb primitives.
This makes google.com not crash in multi-process mode (but there is no
search box.)
The ImageDecoder service now returns a list of image frames, each with
a duration value.
The code for in-process image decoding is removed from LibWeb, an all
image decode requests are sent out-of-process to ImageDecoder. :^)
This won't scale super well to very long and/or large animations, but
we can work on improving that separately. The main goal here is simply
to stop doing any image decoding inside LibWeb.
Fixes#5165.
This fills in a bunch of the FIXMEs that was in prepare_script.
execute_script is almost finished, it's just missing the module side.
As an aside, let's not assert when inserting a script element with
innerHTML.
This was done with the help of several scripts, I dump them here to
easily find them later:
awk '/#ifdef/ { print "#cmakedefine01 "$2 }' AK/Debug.h.in
for debug_macro in $(awk '/#ifdef/ { print $2 }' AK/Debug.h.in)
do
find . \( -name '*.cpp' -o -name '*.h' -o -name '*.in' \) -not -path './Toolchain/*' -not -path './Build/*' -exec sed -i -E 's/#ifdef '$debug_macro'/#if '$debug_macro'/' {} \;
done
# Remember to remove WRAPPER_GERNERATOR_DEBUG from the list.
awk '/#cmake/ { print "set("$2" ON)" }' AK/Debug.h.in
Gfx::Bitmap can now store its scale factor. Normally it's 1, but
in high dpi mode it can be 2.
If a Bitmap with a scale factor of 2 is blitted to a Painter with
scale factor of 2, the pixels can be copied over without any resampling.
(When blitting a Bitmap with a scale factor of 1 to a Painter with scale
factor of 2, the Bitmap is painted at twice its width and height at
paint time. Blitting a Bitmap with a scale factor of 2 to a Painter with
scale factor 1 is not supported.)
A Bitmap with scale factor of 2 reports the same width() and height() as
one with scale factor 1. That's important because many places in the
codebase use a bitmap's width() and height() to layout Widgets, and all
widget coordinates are in logical coordinates as well, per
Documentation/HighDPI.md.
Bitmap grows physical_width() / physical_height() to access the actual
pixel size. Update a few callers that work with pixels to call this
instead.
Make Painter's constructor take its scale factor from the target bitmap
that's passed in, and update its various blit() methods to handle
blitting a 2x bitmap to a 2x painter. This allows removing some gnarly
code in Compositor. (In return, put some new gnarly code in
LibGfxScaleDemo to preserve behavior there.)
No intended behavior change.
