This fixes terminal UI resizing in the vim port. The problem was that
vim had "#ifdef TIOCGWINSZ" around the code that figures out the size
of the terminal.
Since all of our ioctl() requests were enum values, this code was not
compiled into vim at all. This patch fixes that. :^)
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.)
Additionally, we will parse and expose the types of variables
if they are complex, like Enums or Structs. Variables of an enum
type are special in that they do not store all the members of said
enum in their own VariableInfo like Structs do, rather, all of the
values are stored in the VariableInfo for the Enum.
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! :^)
Having these duplicated is not really useful, either we want console
output to go somewhere then implementing a console client is the way to
go, or we don't care about console output - in that case we don't need
to dbg() either.
Object::set_prototype() now returns a boolean indicating success.
Setting the prototype to an identical object is always considered
successful, even if the object is non-extensible.
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.
