Our debug logging when we fail to parse a legitimate selector, is less
useful when it's hidden among selectors that don't parse because they
contain vendor-prefixed pseudo-elements and classes. So, now we
specifically ignore these and don't produce a log message.
When a file deletion event happens, we now iterate over all views of the
FileSystemModel and remove any selection & cursor indices that hold
dangling references do the deleted filesystem node.
This fixes#9602.
getComputedStyle(element) now returns a ComputedCSSStyleDeclaration
object, which is a live view of the computed style of a given element.
This works by ComputedCSSStyleDeclaration being a wrapper around an
element pointer. When you ask it for a CSS property, it gets the latest
computed style values from the element and returns them as a
CSS::StyleProperty object.
This first cut adds support for computed 'color' and 'display'.
In case the element doesn't have a corresponding node in the layout
tree, we fall back to using specified style instead. This is achieved by
performing an on-the-fly style resolution for the individual element and
then grabbing the requested property from that resolved style.
This patch moves the CSS property+value storage down to a new subclass
of CSSStyleDeclaration called PropertyOwningCSSStyleDeclaration.
The JavaScript wrapper for CSSStyleDeclaration now calls virtual
functions on the C++ object.
This is preparation for supporting computed style CSSStyleDeclaration
objects which won't have internal property storage, but rather an
internal element pointer. :^)
Prior this change, the button was updated on user selection change
in the file view.
This isn't quite right, as you could remove the text from the text box
or (even worse) start typing a filename there and the button state
wouldn't change.
When debugging why your website isn't loading in LibWeb the
resource loader is a blind spot as we don't have much logging
except on certain error paths. This can lead to confusing situations
where the browser just appears to hang.
This changes attempts to fix that by adding common success and
failure logging handlers so all resource loading outcomes can
are logged.
We have a few places where we read secrets into memory, and then
do some computation on them. In these cases we should always make
sure we zero the allocations before they are free'd.
The SecureString wrapper provides this abstraction by wrapping a
ByteBuffer and calling explicit_bzero on destruction of the object.
PVS-Studio flagged this, as memset can be optimized away by the compiler
in some cases. We obviously don't want that to ever happen so make sure
to always use `explicit_bzero(..)` which can't be optimized away.
The StyleProperties code for opacity existed before NumericStyleValue
was a thing, and was affected by over-enthusiastic unitless-length
parsing, so it assumed everything was a length. Now it matches the
Color4 spec instead, accepting either a number, or a percentage.
We also get to remove the hack! :^)
Previously, we applied the unitless length quirk to all numbers in
quirks mode. Now, we correctly only do so for the set of properties
listed in the quirks-mode spec:
https://quirks.spec.whatwg.org/#quirky-length-value
However, we do not yet prevent this quirk inside CSS expressions (like
`calc()`) as the spec directs.
After `parse_css_value(PropertyID, TokenStream)`, we only need to know
the current PropertyID when checking for property-specific quirks, which
will take place in only 2 places, which happen deep down. Making the
current PropertyID part of the context means that those places can check
it easily, without us having to pass it to every one of the parsing
functions, which otherwise do not care.
Two CSS quirks are specced to only apply to specific properties:
- The hashless hex color quirk
https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk
- The unitless length quirk
https://quirks.spec.whatwg.org/#the-unitless-length-quirk
These are now represented in `Properties.json` like so:
```json
"property-name-here": {
"quirks": [
"hashless-hex-color",
"unitless-length"
]
}
```
Every property that either of those two quirks applies to is included in
`Properties.json` and now has their quirks listed. :^)
This fixes#9978.
When a TokenStream is empty, reading its `current_token()` still returns
a token (for EOF) so it makes sense to allow users to
`reconsume_current_input_token()` that token, so they do not have to
handle that themselves. Instead of VERIFY()ing, we can just no-op when
reconsuming token 0.
There were a few calls to the standalone version of dump_tree() inside
the recursive version of dump_tree(), which led to the output getting
jumbled out of order.
This is the result of debugging React DOM, which would throw a TypeError
when assigning to window.event in strict mode and then not complete
rendering - here:
cae6350/packages/shared/invokeGuardedCallbackImpl.js (L134)
With this change, the following minimal React example now works!
<div id="app"></div>
<script src="react.development.js"></script>
<script src="react-dom.development.js"></script>
<script>
ReactDOM.render(
React.createElement("h1", null, "Hello World"),
document.getElementById("app")
);
</script>
The [Replaceable] attribute "indicates that setting the corresponding
property on the platform object will result in an own property with the
same name being created on the object which has the value being
assigned. This property will shadow the accessor property corresponding
to the attribute, which exists on the interface prototype object."
(https://heycam.github.io/webidl/#Replaceable)
The spec doesn't tell how exactly this is supposed to be done, but other
engines just have a setter as well that just redefines the property
as a data descriptor when called, and returns undefined.
It's bound to the property name and requires an object of the correct
type, so I mirrored these constraints here. Storing the setter and
calling it multiple times will therefore just work.
Implementing this in the wrapper generator is left as an exercise for
the reader, this is going to be used in WindowObject, which isn't
generated from IDL yet.
There's currently a fallback at the call site where the Realm is needed
(due to a slightly incorrect implementation of [[Call]] / [[Construct]])
so this is better than crashing (in LibWeb, currently).
We need both a GlobalObject and Realm now, but can get the former from
the latter (once initialized).
This also fixes JS execution in LibWeb, as we failed to set the Realm of
the newly created Interpreter in this function.
This method represents the Intl.NumberFormat's [[RelevantExtensionKeys]]
internal slot, so it makes more sense for this to be directly in the
class itself.
To be consistent with the style in Temporal, let's move all AOs in Intl
to their object file, rather than splitting the AOs between prototype
and constructor files.
