Note that as of this commit, there aren't any such throwers, and the
call site in Heap::allocate will drop exceptions on the floor. This
commit only serves to change the declaration of the overrides, make sure
they return an empty value, and to propagate OOM errors frm their base
initialize invocations.
Here .to_string() was being called, which gives an ErrorOr<String>,
then .value() was called on that without any checks. Cases like this
should at least be .release_value_but_fixme_should_propagate_errors()
which makes it clear the error is ignored, but here it's easy to
propagate.
This needs to happen before prototype/constructor intitialization can be
made lazy. Otherwise, GC could run during the C++ constructor and try to
collect the object currently being created.
DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so
let's rename it to A) match the name of DeprecatedString, B) write a new
FlyString class that is tied to String.
Previously when resolving an attr or var-defined property
with a 'not-set' value like this `property: var(--ValueNotSet)`,
we left the property unchanged (as an unresolved) and
added it to the computed-style of the element.
We still don't change the property but rather we now also don't set
unresolved properties in the computed-style.
This is an intended behavior.
The specification suggests that, on resolving an attr or var property
(custom properties) we have an invalid property when neither the
variable inside the var, nor the backup value could be resolved.
An invalid property must be inherited or defaulted depending on it's
type. We already do this with every 'untouched'
(as in m_property_values contains no entry for it) value.
So not setting the property results in an inherited (or initial)
value by a later-called function.
This also fixes another problem, where
`text-decoration: var(--NotSet)`
wouldn't be inherited because the computed-style of the
parent element hasn't set `text-decoration` but rather
all it's long-versions like `text-decoration-line` and so on.
This was wrong twice making it right... But let's fix that.
The center was being passed as a DevicePixelPoint, but was in fact in
CSS pixels, the size was passed as a Gfx::FloatSize but was in
CSS pixels again. Then we were scaling from device pixels to CSS pixels
when painting which does not need to be done if everything is passed
which the correct scale factors already applied.
Note that js_rope_string() has been folded into this, the old name was
misleading - it would not always create a rope string, only if both
sides are not empty strings. Use a three-argument create() overload
instead.
Gfx::Color is always 4 bytes (it's just a wrapper over u32) it's less
work just to pass the color directly.
This also updates IPCCompiler to prevent from generating
Gfx::Color const &, which makes replacement easier.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
