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.
Oops, these were still using the byte-offset cursor. My goodness is it
unergonomic to index into UTF-8 strings, but Dr. Bugaev says it's good.
There is lots of room for improvement here. Just like the rest of the
tokenizer and parser. We'll have to do a few optimization passes over
them once they mature.
We already convert the input to UTF-8 before starting the tokenizer,
so all this patch had to do was switch the tokenizer to use an Utf8View
for its input (and to emit 32-bit codepoints.)
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. :^)
Now that we flush characters in a single place, we can call the Text's
children_changed() from there instead of having a goofy targeted hack
for <style> elements. :^)
Instead of appending character-at-a-time, we now buffer character
insertions in a StringBuilder, and flush them to the relevant node
whenever we start inserting into a new node (and when parsing ends.)
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! :^)
Last night I tried making a little test page that had a bunch of <img>
elements and nothing else. It didn't work.
Fix this by correctly adding a synthesized <html> element to the
document if we get something else in the "before html insertion mode.
Notifying a Resource's clients may lead to arbitrary JS execution,
so we can't rely on the ResourceClient pointers remaining valid.
Use WeakPtr to avoid this problem.
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.
You can still run the old parser with "br -O", but the new one is good
enough to be the default parser now. We'll fix issues as we go and
eventually remove the old one completely. :^)
