This adds a JS console to the bottom section of the Inspector WebView.
Much of this code is based on the existing WebView::ConsoleClient, but
ported to fit the inspector model. That is, much of the code from that
class is now handled in the Inspector's JS.
The Inspector will have an <input> element to execute user-provided JS.
This adds an IDL method and IPC to forward that JS from the Inspector
WebView to the Inspector client.
The spec states that if an input key would insert a numerical character
if it were pressed without a modifier, then the keyCode should be that
of the numerical character. For example, the keyCode for a dollar sign
should be that of the number 4.
Further, we should implement the optional fixed virtual key codes.
Otherwise, our implementation would give e.g. the double quote a keyCode
value of 38, which is the same as the up arrow key.
We need to give pages the opportunity to intercept keydown events and
potentially stop them from propagating. Otherwise, for example, pressing
an arrow key in an <input> element is not observable via script.
The return value of fire_keyboard_event is meant to indicate whether the
event should continue propagating (true) or halt (false). This exactly
matches the return value of dispatch_event, so by negating the result,
we are propagating events we shouldn't, and not propagating events we
should.
We currently fire the change event on <input> elements when they lose
focus. The spec allows for us to also fire the event when changes are
"committed", so long as such an action makes sense for the input type.
This patch detects when the return key is entered in an <input> element
and uses that as the commit action for text-related types. If no change
has occurred since the last commit, no change event is fired.
It is currently a bit messy to pass these options along from main() to
where WebContent is actually launched. If a new flag were to be added,
there are a couple dozen files that need to be updated to pass that flag
along. With this change, the flag can just be added to the struct, set
in main(), and handled in launch_web_content_process().
In order for same-origin NavigableContainers (iframe, frame, embed, ...)
and window.open() WindowProxies to have the proper JS access to their
embedder/opener, we need to host multiple top level traversables in the
same WebContent process. As a first step, make WebContent::PageHost hold
a HashMap of PageClient objects, each holding their own Web::Page that
represents a TraversableNavigable's API surface with the UI process.
The st_mode field in struct stat is a bitfield of more than just the
file type, this commit masks off the non-filetype bits to ensure no
unrelated bits are checked.
RAMFS was passing 0, which lead to the userspace seeing all entries as
DT_UNKNOWN when iterating over the directory contents.
To repro prior to this commit, simply check `echo /tmp/*/`.
We previously left it at the end of the final line, which caused the
next prompt to start offset to the right:
|$ foo^C
| $
This commit makes LibLine move to the beginning of that line,
making it so the next prompt shows up at the beginning of the line:
|$ foo^C
|$
This removes a performance problem where we'd convert the style sheet's
default namespace from DeprecatedFlyString to FlyString once per rule
during selector matching.
The conversion now happens once, during CSS parse. It should eventually
be removed from there as well, but one step at a time. :^)
These tests almost always fail, and all we do is try to boot. Disable it
for now until it can pass more reliably. Note we still compile aarch64,
so the build shouldn't break unnoticed.
Allows the bytecode interpreter to call the builtins c++
implementation directly without making a javascript call
just as the JIT.
Kraken test speedups: imaging-gaussian-blur.js (1.5x) and
audio-oscillator.js (1.2x)
This method takes bytes as input and decompress everything to a
ByteBuffer. It uses two control codes (clear and end of data) as
described in the GIF, TIFF and PDF specifications.
This tries to optimize the refill code by making it easier to digest for
the branch predictor. This includes not looping as much across function
calls and marking our EOF case to be unlikely.
Co-Authored-By: Lucas Chollet <lucas.chollet@free.fr>
Assuming that my changes to make iframes delay the load event are
correct, and that nothing else was causing the flakiness, this test
should be OK now! (Famous last words.)
`<iframe>`s only potentially delay the load event when their
`current_navigation_was_lazy_loaded` flag is false, so let's wire that
up to the flag's setter, and actually call it!
Four elements match the "potentially delay the load event" check in the
spec: `<embed>`, `<frame>`, `<iframe>`, and `<object>`. These four are
the same set of elements that are NavigableContainers (or will be once
we implement them) so let's put this logic there.
Note that other things can delay the load event, this is just the name
the spec gives to this particular behaviour.
`<iframe>` and `<img>` tags share the same spec for several aspects of
lazy-loading: how the `loading` attribute works, the "will lazy load
element" steps, and a member for storing the lazy-load resumption
steps. So let's share the implementation by using a base class.
This mostly involves moving things around. However, we also change the
`start_intersection_observing_a_lazy_loading_element()` method to take
a LazyLoadingElement, and operate on one, instead of always casting to
HTMLImageElement.
We do unfortunately have to do some shenanigans to make the cast work,
by adding a virtual function stub in DOM::Element.
