Store the ratio between device and CSS pixels on the PaintContext, so
that it can convert between the two.
Co-authored-by: MacDue <macdue@dueutil.tech>
GCPtr can be null so it's not safe to assign it to a NonnullGCPtr unless
you know it to be non-null.
This exposed a number of wrong uses in LibWeb which had to be fixed as
part of this change.
This constructor was easily confused with a copy constructor, and it was
possible to accidentally copy-construct Objects in at least one way that
we dicovered (via generic ThrowCompletionOr construction).
This patch adds a mandatory ConstructWithPrototypeTag parameter to the
constructor to disambiguate it.
This generally seems like a better name, especially if we somehow also
need a better name for "read the entire buffer, but not the entire file"
somewhere down the line.
Even if block has all children inline there need to be a check
if it creates BFC because otherwise IFC will be looking in
wrong parent BFC to calculate space used by floats.
This used to be the other way around. If we just inserted input with
document.write, this would always be true and not allow document.write
to immediately parse its input (given that there's no pending parsing
blocking script)
The indexes are into the _node_, not in the fragment, so when a node is
split into multiple fragments, simply taking the length of the fragment
is incorrect. This patch corrects this mistake.
...and also for hit testing, which is involved in most of them.
Much of this is temporary conversions and other awkwardness, which
should resolve itself as the rest of LibWeb is converted to these new
types. Hopefully. :thousandyakstare:
Previously identifiers were resolved to zero length. This could be seen
when a border declaration doesn't have specified width (e.g. `border:
solid`), as the initial border width is 'medium'.
The spec doesn't specify what the identifiers should really resolve to,
but it gives us some example values and that's what I've used here. :^)
Spec link: https://www.w3.org/TR/css-backgrounds-3/#border-width
Discord modals/pop-outs are in a "layerContainer" <div> with
`z-index: 1002`, which then has an immediate child <div> called
"positionLayer" with `z-index: 0`. We only ever hit test child stacking
contexts with z-index set to anything but 0 (step 7 and step 1 of the
hit test), but not for exactly 0 (step 6). This made it impossible to
hit any element inside positionLayer, making pop-ups such as the emojis
and GIFs unusable.
Instead of creating a new global object and proxying everything through
it, we now evaluate console inputs inside a `with` environment.
This seems to match the behavior of WebKit and Gecko in my basic
testing, and removes the ConsoleGlobalObject which has been a source of
confusion and invalid downcasts.
The globals now live in a class called ConsoleGlobalObjectExtensions
(renamed from ConsoleGlobalObject since it's no longer a global object).
To make this possible, I had to add a way to override the initial
lexical environment when calling JS::Interpreter::run(). This is plumbed
via Web::HTML::ClassicScript::run().
