Using JS::Handle in WebEngineCustomData means that mutation observers
will live as long as VM while actually they should be deallocated as
soon as they are no longer used in a script that created them.
There is not need to use SafeFunction because
define_native_function or define_native_accessor will pass callback
forward to NativeFunction that uses HeapFunction to visit it.
This commit introduces 3 things:
- Support for the color type in HTMLInputElement itself
- A mechanism for handling non event loop blocking dialogs in Page
- The associated plumbing up to ViewImplementation
Frontends may add support for the color picker with the
ViewImplementation.on_request_color_picker function
This is 10-20% of a speed increase on platforms with fast I/O (Linux)
and not a slowdown on Serenity. Again, the file system layer is the
limit for us :^)
The internal reuse of FixedMemoryStream makes this straightforward.
There alread is one user of the new API, demonstrating the need for this
change beyond what I said out to use it for :^)
Since it will become a stream in a little bit, it should behave like all
non-trivial stream classes, who are not primarily intended to have
shared ownership to make closing behavior more predictable. Across all
uses of MappedFile, there is only one use case of shared mapped files in
LibVideo, which now uses the thin SharedMappedFile wrapper.
Previously, the same file would be counted more than once if its
containing directory was visited multiple times, or there were
multiple hard links pointing to it.
We now keep track of every visited inode to ensure that files aren't
evaluated multiple times. This matches the behavior of `du` on FreeBSD
and Linux.
Most shorthands can be reconstructed this way, using our generated
property data, so let's use them instead of manually implementing the
code.
Some of these were previously doing some form of error checking or
defaulting, but both of those are unnecessary. (And actually, would
crash if there wasn't a value available due to calling release_nonnull()
on a null RefPtr.) At this point, the CSS machinery has already made
sure each property has a value, and that the value is valid for that
property.
These three are the ones that ShorthandStyleValue uses to serialize
`grid`, so let's use them here.
The spec also mentions `grid-auto-*` properties as being set by `grid`,
but I'll leave that for someone who understands grid better.
When parsing these, <number> is allowed anywhere that would usually
allow a <length>, <length-percentage>, or <angle>. The spec is not
clear on exactly how this should work
(see https://github.com/w3c/svgwg/issues/792 ) so I'm using some
artistic license until things are clearer:
- If we expected a <length>, treat the <number> as pixels.
- If we expected an <angle>, treat the <number> as degrees.
- Only allow direct <number> tokens, not calc() or other functions.
From what I can tell this is what the spec *intended* but I may be very
wrong. In any case, telling the ParsingContext whether we're parsing
one of these attributes is a cleaner approach and more correct than
temporarily enabling quirks mode, which we did previously.
Before the completion_steps for timer were casted from JS::SafeFunction
to Function in HTML::Timer constructor, which is incorrect because then
callback's captured GC-allocated objects are not protected from being
deallocated. Let's modify HTML::Timer to use JS::HeapFunction for the
callback instead.
By using Core::Timer that accepts Function instead of JS::SafeFunction
in Platform::Timer does we fix memory leak caused by circular
dependency of timer's callback and timer itself.
This change implements a step from the document's destroy procedure in
the specification, saying that all active timers should be cleared.
By doing this, we also fix the leaking of a document in case where we
have navigated away from a page that has scheduled timers that haven't
yet been triggered.
aafef1e92d broke this while trying to
make the global import available in initialisation, this commit makes
sure we place the module's own functions after all resolved imports.
If a function that captures a GC-allocated object is owned by another
GC-allocated object, it is more preferable to use JS::HeapFunction.
This is because JS::HeapFunction is visited, unlike introducing a new
heap root as JS::SafeFunction does.
