This patch implements a simple <object> element with fallback content.
If the URL from the data attribute fails to load (including 404),
we render the DOM tree inside the <object> as fallback content.
This works by generating a different layout tree for the <object>
depending on the state and success of the data load. Since we cannot
currently do incremental layout tree updates, we have to force a
complete layout tree rebuild when the resource load finishes/fails.
Since more DOM nodes are going to want to load images (<object>, ...)
this patch splits out the image loading logic into an ImageLoader class
and then HTMLImageElement simply has an ImageLoader.
LayoutImage is then given a const ImageLoader& at construction and can
then provide layout and rendering for many kinds of DOM nodes.
Get rid of the weird old signature:
- int StringType::to_int(bool& ok) const
And replace it with sensible new signature:
- Optional<int> StringType::to_int() const
* 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.
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.
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.
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 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.
Until now we would simply apply stylesheets in the order they finished
loading. This patch adds a StyleSheetList object that hangs off of each
Document and contains all the style sheets in document order.
There's still a lot of work to do for a proper cascade, but at least
this makes us consistently wrong every time. :^)
Subclasses that override Element::parse_attribute() must always call to
base class since otherwise we might forget to parse some attributes.
This makes class selectors work on <body> and <img> elements. :^)
We might end up here with a non-null decoder if the Resource fires load
callbacks again for the resource. It's harmless since we'll just get
the same decoder again.
This patch adds ImageResource as a subclass of Resource. This new class
also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps
between all clients of an image resource inside LibWeb.
With this, we now share both encoded and decoded data for images. :^)
I had to change how the purgeable-volatile flag is updated to keep the
volatile-images-outside-the-visible-viewport optimization working.
HTMLImageElement now inherits from ImageResourceClient (a subclass of
ResourceClient with additional image-specific stuff) and informs its
ImageResource about whether it's inside the viewport or outside.
This is pretty awesome! :^)
This patch introduces a caching mechanism in ResourceLoader. It's keyed
on a LoadRequest object which is what you provide to load_resource()
when you want to load a resource.
We currently never prune the cache, so resources will stay in there
forever. This is obviously not gonna stay that way, but we're just
getting started here. :^)
This should drastically reduce the number of requests when loading
some sites (like Twitter) that reuse the same images over and over.
A Resource represents a resource that we're loading, have loaded or
will soon load. Basically, it's a downloadable resource that can be
shared by multiple clients.
A typical usecase is multiple <img> elements with the same src.
In a future patch, we will try to make sure that those <img> elements
get the same Resource if possible. This will reduce network usage,
memory usage, and CPU usage. :^)
For now, this first patch simply introduces the mechanism.
You get a Resource by calling ResourceLoader::load_resource().
To get notified about changes to a Resource's load status, you inherit
from ResourceClient and implement the callbacks you're interested in.
This patch turns HTMLImageElement into a ResourceClient.
This patch adds two script lists to Document:
- Scripts to execute when parsing has finished
- Scripts to execute as soon as possible
Since we don't actually load scripts asynchronously yet (we just do a
synchronous load when parsing the <script> element for simplicity),
these are already loaded by the time we get to "The end" of parsing.
This seems to have a higher chance of generating somewhat recognizable
content compared to inline layout. This problem will gradually go away
as we implement more display values.
Instead of creating extremely common FlyStrings like "id" and "class"
on demand every time they are needed, we now have AttributeNames.h,
which provides Web::HTML::AttributeNames::{id,class_}
This avoids a bunch of string allocations during selector matching.
Instead of string splitting every time you call Element::has_class(),
we now split the "class" attribute value when it changes, and cache
the individual classes as FlyStrings in Element::m_classes.
This makes has_class() significantly faster and moves the pain point
of selector matching somewhere else.
And move canonicalized_path() to a static method on LexicalPath.
This is to make it clear that FileSystemPath/canonicalized_path() only
perform *lexical* canonicalization.
Now that we've gotten rid of the misguided character buffering in the
tokenizer, it actually spits out character tokens that we have to deal
with in the parser.
This patch implements enough to bring us back to speed with simple.html
Rather than printing them to stderr directly the parser now keeps a
Vector<Error>, which allows the "owner" of the parser to consume them
individually after parsing.
The Error struct has a message, line number, column number and a
to_string() helper function to format this information into a meaningful
error message.
The Function() constructor will now include an error message when
throwing a SyntaxError.
This implements only one of the two forms of this function,
ctx.fill(winding_rule).
Also tweaks the quadratic curve demo to have a nice looking filled
shape.
This display type is implemented using a LayoutBlock that is_inline().
Basically it behaves like a block internally, and its children are laid
out in the normal block layout fashion. Externally however, it behaves
like an atomic inline-level box.
Layout of inline-block boxes happens in three stages:
1. The outer dimensions of the block are computed during the recursive
normal layout pass. We skip positioning, but lay out children.
2. Later on, during line layout in the *containing block*, the inline
block now contributes a linebox fragment. When linebox fragments are
positioned, we learn the final position of the inline block. That's
when we set the inline block's position.
3. We re-layout the inline block's children once again. This is done to
make sure they end up in the right position. The layout tree doesn't
use relative offsets, so after we position the inline block in (2),
its children will not have its positions updated. Relayout moves
all children of inline blocks to the right place.
This is a rather naive approach but it does get the basic behavior into
place so we can iterate on it. :^)
The spec defines the only valid methods to be get, post, and dialog.
Post and dialog are currently unhandled and do nothing, any other value
(or no value specified) is defined by the spec to use the get method.
We now store the response headers in a download object on the protocol
server side and pass it to the client when finishing up a download.
Response headers are passed as an IPC::Dictionary. :^)
A MarkedValueList is basically a Vector<JS::Value> that registers with
the Heap and makes sure that the stored values don't get GC'd.
Before this change, we were unsafely keeping Vector<JS::Value> in some
places, which is out-of-reach for the live reference finding logic
since Vector puts its elements on the heap by default.
We now pass all the JavaScript tests even when running with "js -g",
which does a GC on every heap allocation.
