...instead of maybe bitmap + a single mime type and its corresponding data.
This allows drag&drop operations to hold multiple different kinds of
data, and the views/applications to choose between those.
For instance, Spreadsheet can keep the structure of the dragged cells,
and still provide text-only data to be passed to different unrelated editors.
GIFLoader now tracks the state of errors during the decoding process
and will fall back to displaying the first frame of the GIF if any of
the subsequent frames fail to decode.
The current implementation is lying, it returns negative values if the
inner rect has a zero width or height but also a scrollbar - which
doesn't mean there's a "negative size" available though; it's still "no
size available", i.e. 0.
It's not possible to construct a Gfx::Bitmap with empty size. Let the
client know the new viewport rect and return before even attempting to
create new front and back bitmaps.
Also consider that we might have to paint the widget but not have a
front/back bitmap available (e.g. when only part of a scrollbar is
visible, and the inner rect is empty).
> function f(){f()}f()
Uncaught exception: [RuntimeError]: Call stack size limit exceeded
-> f
1234 more calls
-> (global execution context)
> function a(x){if(x>0){a(x-1)}else{throw Error()}}function b(x){if(x>0){b(x-1)}else{a(5)}}function c(){b(2)}c()
Uncaught exception: [Error]
-> a
5 more calls
-> b
-> b
-> b
-> c
-> (global execution context)
This prevents stack overflows when calling infinite/deep recursive
functions, e.g.:
const f = () => f(); f();
JSON.stringify({}, () => ({ foo: "bar" }));
new Proxy({}, { get: (_, __, p) => p.foo }).foo;
The VM caches a StackInfo object to not slow down function calls
considerably. VM::push_call_frame() will throw an exception if
necessary (plain Error with "RuntimeError" as its .name).
When a mallocation is shrunk/grown without moving, UE needs to update
its precise metadata about the mallocation, since it tracks *exactly*
how many bytes were allocated, not just the malloc chunk size.
This is necessary because cache reusability will be determined by Github Actions.
Note that we only cache if explicitly asked to do so,
which only happens on Github Actions.
Form submissions to file:// URLs are now permitted only if the
submitting document is also a file:// URL and the form method is "get".
Form submissions to URLs with a http(s):// URL protocol are permitted.
Form submissions for all other URL protocols are rejected.
When computing the list of blocks to deallocate when freeing an inode,
we would stop collecting blocks after reaching the inode's block count.
Since we're getting rid of the inode, we need to also include the meta
blocks used by the on-disk block list itself.
Keeping the VM call frames in a Vector could cause them to move around
underneath us due to Vector resizing. Avoid this issue by allocating
CallFrame objects on the stack and having the VM simply keep a list
of pointers to each CallFrame, instead of the CallFrames themselves.
Fixes#3830.
Fixes#3951.
As the global object is constructed and initialized in a different way
than most other objects we were not setting its prototype! This made
things like "globalThis.toString()" fail unexpectedly.
If value.to_string() throws an exception and returns a null string we
must create an invalid StringOrSymbol, not one from the null string
(which ASSERT()s).
* Change the register structures to use the volatile keyword explicitly
on the register values. This avoids accidentally omitting it as any
access will be guaranteed volatile.
* Don't assume we can read/write 64 bit value to the main counter and
the comparator. Not all HPET implementations may support this. So,
just use 32 bit words to access the registers. This ultimately works
around a bug in Bochs 2.6.11 that loses 32 bits of a 64 bit write to
a timer's comparator register (it internally writes one half and
clears the Tn_VAL_SET_CNF bit, and then because it's cleared it
fails to write the second half).
* Properly calculate the tick duration in calculate_ticks_in_nanoseconds
* As per specification, changing the frequency of one periodic timer
requires a restart of all periodic timers as it requires the main
counter to be reset.
