Instead of a StringView. This allows us to preserve the nice O(1) string
compare property of FlyString, and not needing to allocate when one is
needed.
Ideally all other places in Token should have similar changes done, but
to prevent a huge amount of churn, just change ident for now.
https://cldr.unicode.org/index/downloads/cldr-44
Notable changes that affect us include:
* The Islamic Calendar is now localized as the Hijri Calender (in en-US)
but has not been updated for all locales. So this patch updates tests
where possible and removes a few test cases that currently cannot be
localized.
* The und locale has received more likely subtag data (the und locale is
basically a pseudo-locale meaning "undetermined").
* The exponential symbol in the Arabic number system was changed from
U+0627 to U+0623.
It's a little awkward that one caller of this is passing through an
Optional<String> and another an Optional<DeprecatedString>, but that
should be fixed some point in the future with further DeprecatedString
porting.
No IDL file pulls in these requiring DeprecatedString support, so we
are now able to remove these functions! :^)
Also leave a FIXME while we are at it, as ideally this function would
take an Optional<FlyString> - but the IDL generator does not currently
support this.
These were DeprecatedFlyStrings, but had no reason to be. We were not
making use of the O(1) lookup, so instead of porting it over to a
FlyString, just make it a StringView.
This is the API for NamedNodeMap which we are wanting to eventually use
instead of taking a StringView. Currently we just end up deferring to
the StringView versions of these functions, but at some stage in the
future, this will allow us to have O(1) comparison when making attribute
lookups.
In the meantime, the advantage of this API is that it makes it much less
awkward to use than the StringView variant when you have an
Optional<FlyString> namespace to pass through.
The original value 15 was too little: it made our
`weighted_boolean_fair_false` test fail every now and then.
This is because a fair coin (P(false) = 0.5) will hit the same value 15
times in a row with a probability (1/2)^15: around once in a 32k tries.
With the bumped up value, this is now once in 1 billion tries. Should
lower the test flakiness enough (if our random number generator is
truly uniform), while 30 tries is still an OK amount of computation for
randomized tests to do, compared to 15.
Now that x86-specific Assembler will be compiled on every architecture
we can't rely on void* being the right width.
It also fixes compilation on targets which have void*
be different length from u64 (WASM in particular).
This is in preparation for making LibJIT support multiple architectures.
Assembler will now be typedefed to the specific assembler
for a particular architecture.
Additionally, there's now JIT_ARCH_SUPPORTED which is defined on
architectures which LibJIT supports.
This makes JS::JIT::Compiler less architecture-specific
and unifies aligning the stack into a single operation,
where previously we were doing it separately for preserved registers
and for stack arguments.
* Compare array size to 3 and 4, not 4 and 5
* Fix literal typo in error message
Fixes crash processing 0000906.pdf from 0000.zip from the pdf/a dataset.
Representing a text run panting command as a vector of glyphs, rather
than as a string simplifies collecting of unique glyphs which is a
prerequisite for `prepare_glyphs_texture()` call.
Text painting operates in two steps:
1. Preparation of a texture that contains all the glyphs required for
text painting, along with metadata that describes the locations of
those glyphs within texture beforehand.
2. Blitting glyphs from the prepared texture onto corresponding glyph
quads.
Users of LibAccelGfx will need to call `prepare_glyphs_texture()`,
passing a set of all unique (font, code_paint) pairs, before painting
any text.
This change separates a part of the `draw_text_run()` function, which
is responsible for calculating the positions for glyphs that need to be
painted, into a separate function called `get_glyph_run()`.
It is a part of the preparation for text run painting using OpenGL,
where we can't immediately blit glyph bitmaps but instead need to
prepare a sequence of quads for them in advance.
Since 2023-09-08, Clang trunk has had a bug which causes a segfault when
evaluating certain `requires` expressions inside templated lambdas.
There isn't an imminent fix on the horizon, so let's work around the
issue by specifying the type of the offending lambda arguments
explicitly.
See https://github.com/llvm/llvm-project/issues/67260
Using ErrorType::ReferencePrimitiveSetProperty the errors for primitives
now look like "Cannot set property 'foo' of number '123'".
The strict-mode-errors test has been adjusted and re-enabled.
In case of {get func() {}, set func() {}} we were wrongly setting the
function name to 'func' and then later trying to replace an empty name
with 'get func'/'set func' which failed.
Instead, set the name to 'get func'/'set func' right away.
The code in put_by_property_key is kept, for when that is called
by put_by_value.
Previously these were DeprecatedStrings that contained a null state.
After the null state was removed, the nullability of these members was
broken. This doesn't seem to cause any problems currently as the HTML
parser is not inserting attributes with their full qualified name, but
after we fix that problem, this bug surfaces.
The first thing that `set_selection` does is return early if the DOM-
loaded flag is false. Set it to true so it can actually do something.
This fixes inspecting a DOM node from the context menu.
We currently have StylePropertiesModel and AriaPropertiesStateModel in
LibWebView. These depend on GUI::Model and GUI::ModelIndex, which is the
only reason that the non-Serenity Ladybird chromes require LibGUI.
Further, these classes are very nearly idenitical.
This creates a PropertyTableModel to provide the base functionality for
all table-based model types used by all Ladybird chromes. It contains
code common to the style / ARIA table models, and handles the slight
differences between the two (namely, just the manner in which the values
are flattened into a list during construction).
The Qt and Serenity chromes can create thin wrappers around this class
to adapt its interface to their chrome-specific model classes (i.e.
QAbstractItemModel and GUI::Model).
We currently have DOMTreeModel and AccessibilityTreeModel in LibWebView.
These depend on GUI::Model and GUI::ModelIndex, which is the only reason
that the non-Serenity Ladybird chromes require LibGUI. Further, these
classes are very nearly idenitical.
This creates a TreeModel class to provide the base functionality for all
tree-based model types used by all Ladybird chromes. It contains code
common to the DOM / accessibility tree models, and handles the slight
differences between the two (namely, just the formatting of each node's
text for display).
The Qt and Serenity chromes can create thin wrappers around this class
to adapt its interface to their chrome-specific model classes (i.e.
QAbstractItemModel and GUI::Model).
Before this patch, if two or more notifications were created after one
another, they would overlap. This was caused by the previously lowest
notification's m_original_rect being used to calculate the position for
each new notification instead of the notification's actual rect, which
can be different.
This patch makes notifications use each others' rect() method instead,
which makes them appear in the correct position. With that,
m_original_rect has no use anymore, so this patch removes it.
Before this patch, hovering with the mouse over one of at least two
newly created notifications would cause all notifications to be
reordered on the screen, when previously they appeared in order of
creation, growing downwards.
This happened because the position of all notifications is updated when
any of them is hovered, in case the hovered notification was resized.
By using an ordered HashMap instead, creation order is preserved.
This makes use of the new Gfx::Path::text() to handle SVG text elements,
with this text is just a regular path, and can be manipulated like any
other graphics element.
This removes the SVGTextPaintable and makes both <text> and geometry
elements use a new (shared) SVGPathPaintable. This is identical to the
old SVGGeometryPaintable. This simplifies painting as once something is
resolved to a Gfx::Path, the painting logic is the same.
This updates fonts so rather than rastering directly to a bitmap, you
can extract paths for glyphs. This is then used to implement a
Gfx::Path::text("some text", font) API, that if given a vector font
appends the path of the text to your Gfx::Path. This then allows
arbitrary manipulation of the text (rotation, skewing, etc), paving the
way for Word Art in Serenity.
We did convert from the input space to linear space and then
to linear sRGB, but we forgot to re-apply gamma.
This uses the x^2.2 curve instead of the real sRGB curve for now.
This required dealing with a *lot* of fallout, but it's all basically
just switching from DeprecatedFlyString to either FlyString or
Optional<FlyString> in a hundred places to accommodate the change.
When calculating the width of text using a bitmap font, a glyph spacing
is added at the end of each fragment, including the last one. This meant
that everything was 1 pixel too long. This bug did not affect vector
fonts.
For example, on https://html.spec.whatwg.org, there are hundreds of
thousands of nodes. This method is invoked as each node is inserted.
Traversing the entire tree each time takes a prohibitively long time,
so let's bail early when we know the operation is a no-op.
Errantly copied the variable name from the spec. The `node` variable in
this scope is what we passed to Node::insert_before; `node_to_insert` is
what the spec is actually referring to as `node` here.
This kills 2 birds with one stone:
1. It makes sure generated check_exception() calls in the finalizer
don't mis-read the pending exception as caused by their matching
operation.
2. It implicitly ensures that terminated finally blocks (by a return
statement) overwrite any pending exceptions, since they will never
execute the ContinuePendingUnwind operation that restores the
stashed exception.
This additional logic is required in the JIT (as opposed to the
interpreter), since the JIT uses the exception register to store and
check the possibly-exceptional results from each individual operation,
while the interpreter only modifies it when an operation has thrown an
exception.
This reverts commit 0daebef727.
Finally blocks do not unconditionally swallow pending exceptions.
This resolves#21759 and fixes the 2 remaining failing test-js tests.
Previously, we tried to store `VariableInfo` to `ModelIndex` internal
data, but accidently stored address of wrapper class `NonnullOwnPtr`.
When we retrieved it later in `VariablesModel::data()` it made
program to crash.
This allows us to run debug normally after setting any break point in
`HackStudio`.
We can now just unveil the /dev/beep device node, as well as to restrict
the utility functionality for rpath, wpath & stdio related syscalls only
because we don't actually need anything else.
There's no need to have separate syscall for this kind of functionality,
as we can just have a device node in /dev, called "beep", that allows
writing tone generation packets to emulate the same behavior.
In addition to that, we remove LibC sysbeep function, as this function
was never being used by any C program nor it was standardized in any
way.
Instead, we move the userspace implementation to LibCore.
If Interpreter::run_and_return_frame is called with a specific entry
point we now map that to a native instruction address, which the JIT
code jumps to after the function prologue.
Before this change, we were doing it after every layout, which meant
that already-propagated overflow could be propagated again, which led to
incorrect scrolling behavior.
This avoids the O(n) walk of element attributes, although there is still
a huge space for improvement here if we start keeping a lookup cache for
elements-by-ID.
The old name was pretty confusing, since it had nothing to do with the
common "id" content attribute.
This makes way for using id() to return the "id" attribute instead. :^)
We were trying to stringify the stack trace without the last element,
leading to a loop bound of (size_t)(0 - 1) and accessing m_traceback[0]
out-of-bounds.
Instead, just return an empty string in that case.
Fixes#21747
We don't need to make a list of the target node's ancestors before
iterating over them, since nothing happens while iterating them that
can disturb the list anyway (no arbitrary JS execution etc).
The incessant construction and destruction of handles here was showing
up in profiles of basically every website that uses JavaScript to build
some or all of their DOM tree.
In the upcoming changes, Painter will be used to store the state of
OpenGL context. For example, if Painter is aware of the shader that
have already been loaded, it will be possible to reuse them across
repaints. Also, it would be possible to manage state of loaded textures
and add/remove them depending on which ones are present in the next
sequence of painting commands.
The previous implementation was calling `backtrace()` for every
function call, which is quite slow.
Instead, this implementation provides VM::stack_trace() which unwinds
the native stack, maps it through NativeExecutable::get_source_range
and combines it with source ranges from interpreted call frames.
Flip the order from save-registers,enter and leave,restore-registers
to enter,save-register and restore-registers,leave.
This way the return address is next to the saved frame pointer like
unwinding routines expect.
Previously these handlers duplicated code and used formats that
were different from the one Error.prototype.stack uses.
Now they use the same Error::stack_string function, which accepts
a new parameter for compacting stack traces with repeating frames.
Instead of relying on AK_OS_LINUX, actually use the more accurate
HAS_ACCELERATED_GRAPHICS define to figure out if we should try to use
the generic LibAccelGfx GPU painter.
CalRGBColorSpace::color() converts into a flat xyz space,
which already takes input whitepoint into account.
It shouldn't be taken into account again when converting from
the flat color space to D65.
https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf,
8.4 First Four Subrs Entries:
"""If Flex or hint replacement is used in a Type 1 font program, the
first four entries in the Subrs array in the Private dictionary must be
assigned charstrings that correspond to the following code sequences. If
neither Flex nor hint replacement is used in the font program, then this
requirement is removed, and the first Subrs entry may be a normal
charstring subroutine sequence. The first four Subrs entries contain:
Subrs entry number 0:
3 0 callothersubr pop pop setcurrentpoint return
"""
othersubr handler 0 gets three arguments:
* The flex height (the distance after which the bezier splines
are replaced with just straight lines)
* The current position after the flex
It pushes that position on the postscript stack, where predefined subr
handler number 0 then pops it from. It then passes it to
setcurrentpoint.
In theory, we now correctly do that setcurrentpoint call, which we
previously weren't.
In practice, that setcurrentpoint call always receives the last point of
the flex -- and our path api apparently gets confused when move_to() is
called on it when the current point is already at that same location.
So tweak the SetCurrentPoint handler to not set the current point on
the path if it's already the path's current point, with a FIXME to
figure out what exactly is happening in Gfx::Path.
No big behavior change if flex is used, but this is more correct if it
isn't.
(This only works because our `return` handler is empty, else we would
have to make the callothersubr handler start a call frame.)
https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf,
8.4 First Four Subrs Entries:
"""If Flex or hint replacement is used in a Type 1 font program, the
first four entries in the Subrs array in the Private dictionary must be
assigned charstrings that correspond to the following code sequences. If
neither Flex nor hint replacement is used in the font program, then this
requirement is removed, and the first Subrs entry may be a normal
charstring subroutine sequence. The first four Subrs entries contain:
[...]
Subrs entry number 1:
0 1 callothersubr return
Subrs entry number 2:
0 2 callothersubr return
"""
So subr entry numbers 1 and 2 just call othersubr 1 and and 2, which
means we can just move the handling code over.
No behavior change if flex is used, but more correct if it isn't.
(This only works because our `return` handler is empty, else we would
have to make the callothersubr handler start a call frame.)
