| Age | Commit message (Collapse) | Author |
|---|
|
This means we can get rid of the hacks where we were peeking a code
point instead of getting the next one so that we could peek_twin()
later. Now, we follow the spec more closely. :^)
|
|
Same as with would_start_a_number(), we were skipping a code point.
|
|
This fixes the crash that Luke found using Domato:
```css
. foo {
mso-border-alt: solid .-1pt;
}
```
The spec distinguishes between "If the next 3 code points would
start..." and "If the input stream starts with..." but we were treating
them the same way, skipping the first code point in the process.
|
|
These correspond to "If the input stream starts with..." in the spec,
which up until now we were not handling correctly, which led to some fun
bugs.
As noted, reconsuming the input code point in order to read its value is
hacky, but works. Keeping track of the current code point in Tokenizer
would be nicer, when I'm feeling brave enough to mess with it!
|
|
|
|
Note that we don't implement the "context lost steps" yet, so this will
always return the initial value (false).
|
|
|
|
|
|
|
|
This will allow us to easily add copies of the relevant canvas drawing
state to a stack, and likewise replace the current drawing state with
an entry from that stack.
|
|
I don't know if the original author simply missed this or thought the
default color of Gfx::Color is black, but this meant that drawing on a
canvas without explicitly setting a fillStyle or strokeStyle first would
be drawn in transparent color and therefore be invisible.
In the spec this is indicated by a small comment in the IDL definition:
attribute ... strokeStyle; // (default black)
attribute ... fillStyle; // (default black)
I'm starting to question whether Gfx::Color actually *should* have a
default constructor.
|
|
This returned the fill style, not the stroke style!
|
|
This wasn't quite following what the spec says for step 2:
"If index is −1, then remove the last element in the rows collection
from its parent, or do nothing if the rows collection is empty."
It was behaving like:
"If index is −1 and the rows collection is not empty, then remove the
last element in the rows collection from its parent."
Which is not the same, as it will fall into the "Otherwise" if
`index == -1` and the rows collection is empty and try and get the -2nd
element of the rows.
Found with Domato.
|
|
Step 1 of the spec is to capture the <script> element's node document
into a local variable.
When I originally implemented this, I thought this was not necessary.
However, I realised that the script that runs can adopt the current
script element into a different document, meaning step 5.4 and 6 then
operate on the incorrect document.
Covered by this WPT: https://github.com/web-platform-tests/wpt/blob/7b0ebaccc62b566a1965396e5be7bb2bc06f841f/html/semantics/scripting-1/the-script-element/moving-between-documents-during-evaluation.html
|
|
|
|
Also use the HashManager(HashKind) constructor instead of the default
constructor + manual initialize() call.
|
|
This function initially returned a ByteBuffer, so `return {}` was fine.
It was then changed to return Optional<ByteBuffer>, so we accidentally
started returning an empty Optional instead. Explicitly specify the
constructor name to fix this.
Thanks to DexesTTP for catching this!
|
|
|
|
This is a simple implementation of SubtleCrypto.digest() using LibCrypto
under the hood, so it supports all the required hash functions:
SHA-1, SHA-256, SHA-384, SHA-512.
Two FIXMEs remain: doing the hashing "in parallel", and supporting an
object argument instead of a plain string.
|
|
|
|
Just some boilerplate code to get started :^)
This adds both the SubtleCrypto constructor to the window object, as
well as the crypto.subtle instance attribute.
|
|
|
|
|
|
This is from the Encoding Standard (https://encoding.spec.whatwg.org),
and therefore gets its own namespace and subdirectory within LibWeb :^)
|
|
This option is already enabled when building Lagom, so let's enable it
for the main build too. We will no longer be surprised by Lagom Clang
CI builds failing while everything compiles locally.
Furthermore, the stronger `-Wsuggest-override` warning is enabled in
this commit, which enforces the use of the `override` keyword in all
classes, not just those which already have some methods marked as
`override`. This works with both GCC and Clang.
|
|
Being really close to Object.prototype.valueOf() name wise makes this
unnecessarily confusing - while it sometimes serves as the
implementation of a valueOf() function, it's an abstraction which the
spec doesn't have.
Use the appropriate getters to retrieve specific internal slots instead,
most commonly [[FooData]] from the primitive wrapper objects.
For the Object class specifically, use the Value(Object*) ctor instead.
|
|
See: https://github.com/whatwg/dom/commit/cfe2f1e
|
|
|
|
This fixes #11166
|
|
This allows us to see which custom properties apply to a given element,
which previously wasn't shown.
|
|
|
|
We now detect situations like this, where variables infinitely recur,
without crashing:
```css
div {
--a: var(--b);
--b: var(--a);
background: var(--a);
}
p {
--foo: var(--foo);
background: var(--foo);
}
```
|
|
We now stop processing variables once a length of 16384 tokens is
reached. This is an arbitrary number, but should be far beyond what
anyone will reasonably use, and small enough to not crash.
|
|
|
|
If a property is custom or contains a `var()` reference, it cannot be
parsed into a proper StyleValue immediately, so we store it as an
UnresolvedStyleValue until the property is compute. Then, at compute
time, we resolve them by expanding out any `var()` references, and
parsing the result.
The implementation here is very naive, and involves copying the
UnresolvedStyleValue's tree of StyleComponentValueRules while copying
the contents of any `var()`s it finds along the way. This is quite an
expensive operation to do every time that the style is computed.
|
|
This represents a property value that hasn't been converted to a
"proper" StyleValue yet. That is, it's either a custom property's value,
or a value that includes `var()` references, (or both!) since neither of
those can be fully resolved at parse time.
|
|
For our naive var() implementation, we need to be able to create
StyleBlockRules outside of the Parser, and these changes make that
possible.
|
|
|
|
|
|
This allows JS to keep an element alive by retaining a reference to
element.attributes
|
|
This allows document.implementation to keep the underlying document
alive for as long as we need it (for example, if someone holds on to a
DOMImplementation JS wrapper after the document is GC'd.)
|
|
This object already forwarded its ref count to DOM::Window. This patch
simply adopts the new RefCountForwarder base to achieve the same thing.
|
|
This allows us to use TRY() or MUST() when calling it.
|
|
It's not safe for this to be a raw pointer, as the child can outlive the
parent.
|
|
It's not safe for this to be a raw pointer, as the imported style sheet
can outlive the rule.
|
|
It's not safe for this to be a raw reference, as CSSImportRule can
outlive the document.
|
|
|
|
The "completely finish loading" algorithm (from the HTML spec) is
responsible for sending a "load" event to nested browsing context
containers (iframes).
This patch removes the old mechanism for sending "load" events, which we
had mistakenly kept around, causing two events to be sent instead of
one. :^)
|
|
DOMImplementation.createDocument() should set the content type of the
newly created document, not replace the content type of the
DOMImplementation's own host document.
|
|
This allows us to use TRY() in decoding helpers, leading to a nice
reduction in line count.
|
