These now crash as VM::call() uses ThrowExceptionOr<T>, which refuses to
hold an empty JS::Value as its non-exception result.
We only need to return an empty value when should_return_empty() says
so for the return value of throw_dom_exception_if_needed().
Co-authored-by: Luke Wilde <lukew@serenityos.org>
Looking at how these two constants are commonly used in other systems,
we should be able to mimic their behavior using our PT_PEEK constant.
For example, see:
https://man.netbsd.org/NetBSD-6.0.1/i386/ptrace.2
Previously any children would be layout using a BlockFormattingContext.
Now we at least differentiate between IFC and BFC if the sizes in
question are not constrained by other things.
Calling `is_identifier()` here was wrong, since it just means you can
get an Identifier from it. This meant that an `auto` LengthStyleValue
would return true, then it would get `static_cast` to the wrong class,
and return a garbage value.
Basically, I really need to tidy up the API for StyleValue, so it's
clear whether `is_foo()` means the object is a `FooStyleValue`, or it
can just return a `foo` value.
For `number` and `integer` types, you can add a range afterwards to add
a range check, using similar syntax to that used in the CSS specs. For
example:
```json
"font-weight": {
...
"valid-types": [
"number [1,1000]"
],
...
}
```
This limits any numbers to the range `1 <= n <= 1000`.
This brings us a few nice benefits:
- We only generate a `StyleValueList` for properties that accept
multiple values.
- We reject declarations that have too many values.
- We check the type of each value that is parsed, to make sure it's
acceptable to the property.
Probably there are some regressions here, since this is
Later, we can also replace many of the `is_foo()` functions and lambas
inside the Parser with more calls to `property_accepts_value()`. Also we
can remove some checks when resolving styles, since only valid types of
values will get to that point. But one step at a time. :^)
Previously, we have not been validating the values for CSS declarations
inside the Parser. This causes issues, since we should be discarding
invalid style declarations, so that previous ones are used instead. For
example, in this code:
```css
.foo {
width: 2em;
width: orange;
}
```
... the `width: orange` declaration overwrites the `width: 2em` one,
even though it is invalid. According to the spec, `width: orange` should
be rejected at parse time, and discarded, leaving `width: 2em` as the
resulting value.
Many properties (mostly shorthands) are parsed specially, and so they
are already rejected if they are invalid. But for simple properties, we
currently accept any value. With `property_accepts_value()`, we can
check if the value is valid in `parse_css_value()`, and reject it if it
is not.
We don't want a property like `background` to fall back to parsing as a
single value or StyleValueList if `parse_background_style_value()`
fails. We just want it to fail.
We need to exclude this file from analysis for now, as there is a bug in
the sonar-runner tool where it crashes when trying to understand the use
of AK::Variant in LibWasm/Parser/Parser.cpp
See #10122 for details + link to the bug report to Sonar Cloud.
I was experimenting with using caching while doing the initial prototype
of the Sonar Cloud workflow. However the cache size for the static
analysis data ended up being large enough that it would put us over the
git hub actions limit. Given that we currently only run this pipeline
once a day, it seems reasonable to just remove caching.
If in the future we decide to run the pipeline on every PR, caching
would become crucial as the current un-cached analysis time is around
1 hour and 50 minutes. If we did this we would need to move the pipeline
to Azure DevOps where we have effectively infinite cache available.
Prior this commit we were always dereferencing the image bitmap pointer,
even if it was null, which resulted in a crash when trying to open
the context menu when an image wasn't loaded.
Closes: #10178
