The decoder assumes that k's sampling factor matches y's at the moment.
Better to error out than to silently render something broken.
For ycck, covered by ycck-2111.jpg in the tests.
This scan code set is more advanced than the basic scan code set 1, and
is required to be supported for some bare metal hardware that might not
properly enable the PS2 first port translation in the i8042 controller.
LibWeb can now also generate bindings for keyboard events like the Pause
key, as well as other function keys (such as Right Alt, etc).
The logic for handling scan code sets is implemented by the PS2 keyboard
driver and is abstracted from the main HID KeyboardDevice code which
only handles "standard" KeyEvent(s).
Instead of using a scan code, which for scan code set 2 will not
represent the expected character mapping index, we could just use
another variable in the KeyEvent structure that correctly points to the
character index.
This change is mostly relevant to the KeyboardMapper application, and
also to the WindowServer code, as both handle KeyEvents and need to
use the character mapping index in various situations.
We currently assume that the K (black) channel uses the same sampling
as the Y channel already, so this already works as long as we don't
error out on it.
We can now implement steps related to resizable ArrayBuffer objects. We
can also implement a couple of missing SharedArrayBuffer checks.
The original implementation of this proposal did not have any tests, so
tests are added here for the whole implementation.
The BatchingDispatcher mechanism is used by HTMLImageElement to avoid
decoding one image at a time, since interleaving decode/layout/repaint
over and over takes way more time than doing many decodes followed by
a single layout/repaint pair.
Before this change, we didn't have a limit on how many batched loads
we'd allow ourselves to queue up, which could lead to situations where
more and more images kept being added to the queue, and never getting
processed.
This fixes the issue by putting an arbitrary limit (16) on the number
of batched image loads, and then allowing the flush to happen after
that instead of re-deferring processing.
If an image element has no alt attribute, other browsers don't fall back
to using the src attribute like we did.
This gave us a janky look while loading pages that other browsers don't
have, and it's not like seeing a partial URL is really helpful to the
user anyway.
In: https://tc39.es/ecma262/#sec-%typedarray%-intrinsic-object
The spec says:
> is a constructor function object that all of the TypedArray
> constructor objects inherit from.
From what I understand from this, it effectively just means is that the
prototype for the constructor should simply be set to
TypedArrayConstructor. We _were_ doing that, but also inheriting from
it in C++.
This meant we were invoking TypedArrayConstructor::initialize for each
of the typed arrays. This is not actually what we want, since it means
that the 'of' and 'from' functions were being defined as native
properties in both the concrete typed array (e.g Uint8Array), and the
abstract TypedArray. Instead, the properties should only be defined and
inherited from the abstract TypedArray class.
Diff Tests:
+4 ✅ -4 ❌
Co-Authored-By: Andreas Kling <kling@serenityos.org>
Instead, we now pass String if we have one. In particular, this fixes an
issue where image elements with a data: URL src would copy the entire
URL string every time we painted (before the image had been decoded).
This was very noticeable on "fully downloaded" web pages where every
single image has been turned into a data: URL.
This code didn't account for position:fixed elements, which meant that
we'd swallow repaints for such elements when the viewport wasn't
scrolled to the top of the page.
We replace the incomplete optimization with a FIXME noting that this
needs to be handled correctly when reintroduced.
This is a cleanup patch, moves a chunk of repeated code to one place
instead of assigning variables with the same values twice in two
different places of code.
Currently if users select last bytes in HexEditor with mouse in either
Hex or Text mode, they will be able to move cursor on the byte outside
bounds. If then they try to write something in either of those modes,
app will crash.
This patch moves the recently added "replace" cursor to always be on the
last byte of the selection instead of being on the byte after the last
selected byte.
This patch changes cursor type from caret to black box for both Hex and
Text modes, because right now the way how blinking caret looks like is
more closer to "insert" mode in similar editors, whereas the real
behavior of this cursor is more of a "replace" mode seen in similar
editors like GHex.
This stopped being called for anything without a navigable container
after 76a97d8, due to the early return. This broke SVG <use> elements
that reference elements defined later in the document.
This also removes the code for displaying `gemini://` documents. We
currently don't load documents from that protocol anyway - we hit
`attempt_to_create_a_non_fetch_scheme_document()` in `Navigable.cpp`
which is just a stub. It looks like we should be handling those
separately from regular "fetch" documents, so that's a task for a
future person.
(Apologies for bad commit title, it's hard to explain in such a short
space!)
We're going to need to call this for producing markdown and gemini
documents, both of which need a Document and Realm to fetch the entire
response body, so that they can then generate their HTML. So this
commit modifies `create_document_for_inline_content()` to take a lambda
instead of a fixed HTML string, to support these uses.
Also, we always return a nonnull pointer, so make that the return type.
This is a move and change in the same commit, (Sorry!) but all the
changes are to the function signature and step 6.
There's an unfortunate hack here. We have to load the media file's data
before we call `HTML::HTMLParser::the_end()` with our generated
document, otherwise the media element (`<img>`/`<audio>`/`<video>`)
never loads and that blocks the document's load event. The previous code
path also did this, which is perhaps why the bug was never noticed.
