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.
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 commit makes LibLine handle interrupts (as reported via
interrupted() and resized()) again.
There is a little catch with the shell:
```
$ ls |
pipe> <C-c> (prompt stays here until a key is pressed)
```
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. :^)
When parsing JavaScript, we can get pretty much any sequnce of tokens,
and we shouldn't crash if it's not something that we normally expect.
Instead, emit syntax errors.
In C++, it's invalid to cast a block of memory to a complex type without
invoking its constructor. It's even more invalid to simply cast a pointer to a
block of memory to a pointer to *an abstract type*.
To fix this, make sure FreelistEntry is a concrete type, and call its
constructor whenever appropriate.
This rewrite drastically increases the accuracy of object literals.
Additionally, an "assertIsSyntaxError" function has been added to
test-common.js to assist in testing syntax errors.
You can now request an update of the terminal's window progress by
sending this escape sequence:
<esc>]9;<value>;<max_value>;<escape><backslash>
I'm sure we can find many interesting uses for this! :^)
Each window now has an associated progress integer that can be updated
via the SetWindowProgress IPC call.
This can be used by clients to indicate the progress of ongoing tasks.
Any number in the range 0 through 100 indicate a progress percentage.
Any other number means "no progress"
