Keep track of which CSSRule owns a CSSRuleList, and then use that to
produce a stack of RuleContexts for the CSS Parser to use.
There are certainly other places we should do this!
The spec algorithm changed at some point to support nested declarations,
but I only just noticed. The subtest regression is one we were passing
incorrectly.
Type changes are now signaled to radio buttons. This causes other radio
buttons in the group to be unchecked if the input element is a checked
radio button after the type change.
similar-origin window agents have the [[CanBlock]] flag set to false.
Achieve this by hooking up JS's concept with an agent to HTML::Agent.
For now, this is only hooked up to the similar-origin window agent
case but should be extended to the other agent types in the future.
We were missing the step to use realm's global object if thisValue
was nullish. This is very trivial to fix, as `impl_this` already
handles everything as it should, allowing us to also remove the
special casing for WindowProxy.
Previously, `CSSStyleSheet.replace()` and `CSSStyleSheet.replaceSync()`
parsed the given CSS text into a temporary stylesheet object, from
which a list of rules was extracted. Doing this had the unintended
side-effect that a fetch request would be started if the given CSS text
referenced any external resources. This fetch request would cause a
crash, since the temporary stylesheet object didn't set the constructed
flag, or constructor document. We now parse the given CSS text as a
list of rules without constructing a temporary stylesheet.
This was actually an older change to the Streams spec that we missed
when we implemented TransformStreams. This fixes a crash in the imported
WPT tests.
See: https://github.com/whatwg/streams/commit/007d729
There is an open issue to clarify exactly what realm is to be used when
creating promises. There are surely many more places we will need to
update to use the correct realm (which will be the realm of `this`'s
relevant global object).
If the user clicked directly on the input inside a label, then it
already received a click event. Dispatching a second one via the label
is redundant, and means that if the input is a checkbox, it gets its
value toggled twice.
I don't quite see what spec text requires this, but it is explicitly
checked by WPT. We used to pass this test, but that regressed after
commit 3c6010c663.
This required a bit of manual manipulation. These tests dynamically
fetch generated IDL files, e.g.:
https://github.com/web-platform-tests/wpt/blob/master/interfaces/streams.idl
Our WPT importer is not able to detect the IDL files that need to be
imported, so dom.idl and streams.idl was copied over manually. Further,
idlharness.js would create URLs of the form "file://interfaces/dom.idl".
So idlharness.js was adapted to create a URL relative to the test file.
This widens the assertion from only checking if the WritableStream's
state is Errored or Erroring to asserting that the WritableStream is not
in a Writable state.
