Style updates are lazy since late last year, so the StyleInvalidator is
actually hurting us more than it's helping by running the entire CSS
selector machine on the whole DOM for every attribute change.
Instead, simply mark the entire DOM dirty and let the lazy style update
mechanism run *once* on next event loop iteration.
Instead of making each Layout::Node compute style for itself, we now
compute it in TreeBuilder before even calling create_layout_node().
For non-element DOM nodes, we create the style and layout tree node
in TreeBuilder. This allows us to move create_layout_node() from
DOM::Node to DOM::Element.
ECMA-262 defines \s as:
Return the CharSet containing all characters corresponding to a code
point on the right-hand side of the WhiteSpace or LineTerminator
productions.
The LineTerminator production is simply: U+000A, U+000D, U+2028, or
U+2029. Unfortunately there isn't a Unicode property that covers just
those code points.
The WhiteSpace production is: U+0009, U+000B, U+000C, U+FEFF, or any
code point with the Space_Separator general category.
If the Unicode generators are disabled, this will fall back to ASCII
space code points.
Among other things, this lets you run flaky tests to check if they are
still flaky. :^)
This is done in two ways: It makes should_skip_test() always return
false; and skips reading and generating the skipped-tests lists since
we won't use them.
This partially reverts commit a962ee020a.
When the sticky bit is set, the global bit should basically be ignored
except by external callers who want their own special behavior. For
example, RegExp.prototype [ @@match ] will use the global flag to
accumulate consecutive matches. But on the first failure, the regex
loop should break.
The "at most n bytes" behaviour of strncmp is required for this logic to
work, this was overlooked in 5b64abe when converting Strings to
StringViews, which lead to broken autocomplete.
Since the spec does not fully define the entry points of modules what
this means is kind of unclear. But it does work in most cases and can
be useful. We do print out a warning just to clarify why there could be
strange things.
It seems the stack search does not find all functions because they are
kept in variants and other structs. This meant some function could be
cleaned up while we were evaluating a class meaning it would fail/crash
when attempting to run the functions.
This feature had bitrotted somewhat and would trigger errors because
PrimitiveStrings were "destroyed" but because of this mode they were not
removed from the string cache. Even fixing that case running test-js
with the options still failed in more places.
This statement (for now) outputs the name and types of the different
attributes in a table. It's not standard SQL but all DBMSs that I know
of implement a sort of statement for such functionality.
Since the output of DESCRIBE TABLE is just a relation, an internal
schema, `master` was created and a table definition for DESCRIBE into
it. The table definition and the master schema are not accessible by the
user.
LibRegex already implements this loop in a more performant way, so all
LibJS has to do here is to return things in the right shape, and not
loop over the input string.
Previously this was a quadratic operation on string length, which lead
to crazy execution times on failing regexps - now it's nice and fast :^)
Note that a Regex test has to be updated to remove the stateful flag as
it repeats matching on multiple strings.
The first line was creating a StringView object with region name. Then,
if the path didn't start with '/', it had assigned a String made from a
temporary LexicalPath join result.
This fixes the bug that only main executable's frames were displayed.
Now while dragging a new rectangular selection you can cancel it by
hitting Escape. Existing selections are cleared by Escape as well if the
RectangularSelectTool is active.
This is a normative change in the ECMA-262 spec:
https://github.com/tc39/ecma262/commit/ca53334
Note that this also fixes a few errors where we errantly converted the
stored time value to local time.
Modified the test-page because FontDatabase looks for exact font-weight
matches, so requesting weight 800 in a font that only has 700, causes
it to return the default font instead. So, we ask for 700 here.
The actual fix is to improve our font-matching but I am trying not to
get distracted today. :^)
None of these require any outside metrics, which is nice! I believe the
Values-4 spec would have us simplify them down into a single value at
parse time, but that's a yak for another day.
Most of the time, we cannot resolve a `calc()` expression until we go to
use it. Since any `<length-percentage>` can legally be a `calc
()`, let's store it in `LengthPercentage` rather than make every single
user care about this distinction.
The previous static functions are now methods of their respective
CalcFoo structs, but the logic has not changed, only that they work
with CalculationResults instead of converting everything to floats.
calc() sub-expressions can return a variety of different types, which
then can be combined using the basic arithmetic operators. This class
should make that easier to deal with, instead of having to handle all
the possible combinations at each call site. :^)
We take the Layout::Node as a pointer not a reference, since later we'll
need to call these functions when resolving to `<number>` or `<integer>`
which don't use those, and we don't want to force users to pass them in
unnecessarily.
See https://www.w3.org/TR/css-values-3/#calc-type-checking
If the sub-expressions' types are incompatible, we discard the calc() as
invalid.
Had to do some minor rearranging/renaming of the Calc structs to make
the `resolve_foo_type()` templates work too.
