The box tree and line boxes now all store a relative offset from their
containing block, instead of an absolute (document-relative) position.
This removes a huge pain point from the layout system which was having
to adjust offsets recursively when something moved. It also makes some
layout logic significantly simpler.
Every box can still find its absolute position by walking its chain
of containing blocks and accumulating the translation from the root.
This is currently what we do both for rendering and hit testing.
There was a logic mistake in the entity parser that chose the shorter
matching entity instead of the longer. Fix this and make the entity
lists constexpr while we're here.
* A PageView is a view onto a Page object.
* A Page always has a main Frame (root of Frame tree.)
* Page has a PageClient. PageView is a PageClient.
The goal here is to allow building another kind of view onto
a Page while keeping the rest of LibWeb intact.
Objects should get the GlobalObject from themselves instead. However,
it's not yet available during construction so this only switches code
that happens after construction.
To support multiple global objects, Interpreter needs to stop holding
on to "the" global object and let each object graph own their global.
This patch introduces support for more than just "absolute px" units in
our Length class. It now also supports "em" and "rem", which are units
relative to the font-size of the current layout node and the <html>
element's layout node respectively.
Now that PageView actually respects the invalidation rect provided by
the layout system, it turns out we were invalidating too little.
Unfortunately, this is not really fixable until the initial containing
block starts having the right size (same as viewport), but that will
require a bunch of work to make overflow work again. So it's a FIXME
for now, and we'll return to this.
When a paint invalidation occurs inside a subframe, it bubbles up to
Frame::set_needs_display(). From there, we call PageView if this is
the main frame, or otherwise invalidate the subframe host element.
We don't support incremental relayout of subtrees (only single nodes)
but let's not crash the browser just because this happens. We can keep
the browser up and just complain in the debug log instead.
While we're parsing a new document, we don't have a Frame to grab at.
We now use the Node::document_did_attach_to_frame() notification hook
to delay subframe construction.
With this, subframes now always have a valid reference to their
enclosing main frame.
Also, if the request URL is a data: URL, use the MIME type from the URL
itself if available. This makes it possible to load arbitrary MIME type
data: URLs in the browser :^)
Returning it by reference can lead to unpleasant situations if we use
this getter when the document may go away. Better to make the getter
return a copy than have to think about this everywhere.
This patch introduces a bunch of things:
- Subframes (Web::Frame::create_subframe())
- HTMLIFrameElement (loads and owns the hosted Web::Frame)
- LayoutFrame (layout and rendering of the hosted frame)
There's still a huge number of things missing, like scrolling, overflow
handling, event handling, scripting, etc. But we can make a little
iframe in a document and it actually renders another document there.
I think that's pretty cool! :^)
This was a confusing bug: ImageStyleValue loaded its image resource as
a Generic resource, while HTMLImageElement loaded as Image.
This patch fixes the issue and adds an assertion to verify that we only
share resources that have the same C++ client class type.
LayoutReplaced now has intrinsic width, height and ratio. Only some of
the values may be present. The layout algorithm takes the various
configurations into account per the CSS specification.
This is still pretty immature but at least we're moving forward. :^)
This makes stuff inside <noscript> correctly not show up since we run
with scripting enabled.
In the future, we can add a way to disable scripting, but for now,
Document::is_scripting_enabled() just returns true.
When handling a "textarea" start tag, we have to ignore the next token
if it's an LF ('\n'). However, we were not switching the tokenizer
state before fetching the lookahead token, and this caused us to force
the tokenizer into the RCDATA state too late, effectively getting it
stuck in that state for way longer than it should be.
Fixes#2508.
