I originally implemented this as something to use the new sequence
wrapper, however, after having a look at uses with grep.app, it's used
often, for example:
- Bootstrap 5 Dropdowns
- Polymer
- Angular
- Closure
Previously, when the last layer got deleted, the active layer was
set to nullptr, causing a crash.
Now, we create a new transparent background layer with the image
dimensions instead.
We want to check the last SimpleSelector, not the first one. We don't
have to check that a SimpleSelector exists since a CompoundSelector
without one is invalid.
Also, renamed `builder` to `s` to match spec comments, and fixed a
find-and-replace typo where some pseudo-class names were
"last-of-pseudo_class" instead of "last-of-type".
This implements these algorithms from the CSSOM-1 spec:
- serialize a string
- serialize a URL
Also, we now have two versions of each of the serialization functions:
One that returns a String as before, and the other that takes a
StringBuilder to write into. This saves creating extra StringBuilders
when they are not needed. :^)
All its members are comparable themselves, so this can be defaulted.
Making it comparable will allow us, among other things, to check if a
list of symbols (i.e., the result of calling the symbolicate functions)
is equal or not to another, which in turn will allow us to avoid
refreshing the SystemMonitor's Stack tab when successive symbolicated
stacks are the same.
This function converts a single wide character into its multibyte
representation (UTF-8 in our case). It is called from libc++'s
`std::basic_ostream<wchar_t>::flush`, which gets called at program exit
from a global destructor in order to flush `std::wcout`.
Previously, `box-shadow: none` would fail to parse, meaning that in this
example:
```css
p {
box-shadow: 20px 10px 5px magenta;
}
p.foo {
box-shadow: none;
}
```
... a `<p class="foo">` would still have a box-shadow, when it should
not have one. Now, we handle the `none` value. :^)
https://www.w3.org/TR/cssom/ is the more permanent home of the CSSOM
specification's latest version, and is up to date with the draft spec.
Also, https://drafts.csswg.org/ has been down multiple times recently
which made looking things up a pain.
The `CSSMediaRule::serialized()` code is to spec. The
`CSSSupportsRule::serialized()` code has no spec right now, but I'm
fairly confident it will be almost identical to media's, so I copied
that for now.
This saves having to save and load the parser state.
This could give an incorrect token in some cases where the parser
communicates to the lexer. However this is not applicable in any of the
current usages and this would require one to parse the current token
as normal which is exactly what you don't want to do in that scenario.
There used to be the silly bug that when the cursor was already at the
end of a span (e.g. because the user just pressed Ctrl-Right), then
Ctrl-Right had no effect.
This bug does not appear with Ctrl-Left because due to the order in
which the spans are iterated, the effective result is always correct.
This patch also makes it more apparent that the algorithm is
unnecessarily inefficient.
Previously, the initial call to update_selection() was missing, so if no
text was already selected, then Ctrl-Shift-End would only move the
cursor to the document end, but not select any text.
Well... sort of. This adds the function itself and all the scaffolding
from the ShadowRealm API (and basically completes its implementation).
However, we do not nearly have enough support for modules and imports,
so we currently pretend whatever was attempted to be imported failed -
once we have HostImportModuleDynamically it should be relatively easy to
complete the implementation.
Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`,
meaning you got:
```js
1n == Object(1n); // true
Object(1n) == 1n; // false
```
This also adds spec comments to is_loosely_equal.
This is just another workaround, but it should be much more reliable
than Interpreter::realm(), especially when allocating NativeFunctions
and ECMAScriptFunctionObjects: we're guaranteed to have a GlobalObject
at that point, and it likely was set as the GlobalObject of a Realm and
can lead us back to it. We're however not guaranteed that the VM can
give us an Interpreter, which is why functions in LibWeb can be a bit
crashy at the moment.
We use a WeakPtr<Realm> to properly handle the unlikely case where the
Realm goes away after associating a GlobalObject to it.
We'll always need _something_ of this sort if we want to support
OrdinaryFunctionCreate and CreateBuiltinFunction without the explicit
realm argument while no JS is running, because they want to use the
current Realm Record (always in the first and as fallback in the second
case).
