This makes React react to checkboxes. Apparently they ignore the
"change" event in favor of "click" on checkboxes. This is a
compatibility hack for IE8.
By storing count as an Optional<size_t>, we can leverage count's empty
state to proceed with pinging indefinitely, and ensure a proper value is
passed when count does have a value.
This returns pings expected behavior to send infinite packets when a
count is not specified, stop after sending a specified count, and
disallow any count < 1.
Closes#12524
Currently this method always succeeds, but that won't be true once we
switch to the Core::Stream API. :^)
Some of these places would ideally show an error message to the user,
since failure to save a file is significant, but let's not get
distracted right now.
This moves the fallible action of opening the file, from the
constructor, into the factory methods which can propagate any errors.
The wrinkle here is that failure to open a ConfigFile in read-only mode
is allowed (and expected, since the file may not exist), and treated as
if an empty file was successfully opened.
I've attempted to handle the errors gracefully where it was clear how to
do so, and simple, but a lot of this was just adding
`release_value_but_fixme_should_propagate_errors()` in places.
While the code did already VERIFY that the ErrorOr holds a value, this
was done by Variant, so the error message was just that `has<T>()` is
false. This is less helpful than I would like, especially if backtraces
are not working and this is all you have to go on. Adding this extra
VERIFY means the assertion message (`!is_error()`) is easier to
understand.
Once we paint, it's way too late for this check to happen anyway.
Additionally, the spec's steps for retrieving the content document
assume that both the browsing context's active document and the
container's node document are non-null, which evidently isn't always the
case here, as seen by crashes on the SerenityOS 2nd and 3rd birthday
pages (I'm not sure about the details though).
Fixes#12565.
This is not a complete implementation of API, since we're also supposed
to accept an options dictionary as the third argument. However, a lot of
web content uses the boolean variant, and it's trivial to support.
I can't imagine how this happened, but it seems we've managed to
conflate the "event listener" and "EventListener" concepts from the DOM
specification in some parts of the code.
We previously had two things:
- DOM::EventListener
- DOM::EventTarget::EventListenerRegistration
DOM::EventListener was roughly the "EventListener" IDL type,
and DOM::EventTarget::EventListenerRegistration was roughly the "event
listener" concept. However, they were used interchangeably (and
incorrectly!) in many places.
After this patch, we now have:
- DOM::IDLEventListener
- DOM::DOMEventListener
DOM::IDLEventListener is the "EventListener" IDL type,
and DOM::DOMEventListener is the "event listener" concept.
This patch also updates the addEventListener() and removeEventListener()
functions to follow the spec more closely, along with the "inner invoke"
function in our EventDispatcher.
This basically copies some logic from FrameLoader to ImageLoader.
Ideally we'd share this code, but for now let's just get redirected
images to show up. :^)
These APIs return Strings, which are OOM-infallibe, and as such, not
appropriate for Kernel use. Since these APIs are only used by userland
at the moment, we can just ifdef them out of the Kernel.
