Fixes#5736. The selected note value could also underflow if
you drag to the left, but the assert got triggered only in
case you're dragging past the end of the note roll.
This commit makes sure that we fail if an encoded lz77 back reference
references bytes that are outside our sliding window, instead of just
silently failing, which triggers an assertion down the line.
Instead of counting the number of call frames on the VM stack, we now
always fake the "arguments" object when the current call frame has
a callee value.
This fixes an issue with DOM event handlers in LibWeb not being able
to access "arguments" since they were called without an outer frame.
This makes GCC emit warnings about redundant and pessimizing moves.
It also allows static analyzers like clang-tidy to detect common bugs
like use-after-move.
With a little help (read: copy & paste) from ImageWidget, QuickShow will
now cycle through the frames of animated images - enjoy the cat GIFs!
Future improvement: cache decoded images like LibWeb's ImageResource to
waste less CPU - the same applies to LibGUI though, maybe we can put
something shared in LibGfx.
Closes#5837.
The image decoder already tells us whether the image is animated and it
can provide more than one frame, let's not put this behind an artificial
"file path must end with lowercase .gif" barrier.
Since we were not checking for error flags set by read_bits we would
just always read 0 as the bits' value, which in some edge cases could
lead to an infinite loop.
We now read the header into a temporary header byte array that is used
as the header once its filled up by the input stream, instead of just
ending the stream if we are out of bytes mid header.
At the cost of using more read() syscalls, process the DSR response
character-by-character.
This avoids blocking forever waiting for an 'R' that will never come :P
Checking for the existence of a call frame is not enough to check if
we're in a function call, as the global execution context is a regular
call frame as well.
Found by OSS-Fuzz, where simply accessing "arguments" in the global
scope would crash due to call_frame().callee being an empty value
(https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32115).
It's a little awkward that we do this in two places, but IPWV and OOPWV
currently implement resizing a little differently from each other so we
need to cover both paths.
This was a kludge to paint ComboBox editors before the advent of
accessory windows, isn't being used anymore, and was inadvertently
letting two ComboBoxes paint as if both had focus.
This commit makes read short-circuit if its input stream errored,
as well as propagate error handling to wrapped sub streams, similarly
to DeflateDecompressor.
In the case that both the stream and the wrapped substream had errors
to be handled only one of the two would be resolved due to boolean
short circuiting. this commit ensures both are handled irregardless
of one another.
This will be used by ImageData objects in LibWeb since the web spec
says these store colors in RGBA8888 order.
The only thing you can do with this format right now is blitting it
onto a BGRA8888 bitmap.
The previous names (RGBA32 and RGB32) were misleading since that's not
the actual byte order in memory. The new names reflect exactly how the
color values get laid out in bitmap data.
For various statements the spec states:
Return NormalCompletion(empty).
In those cases we have been returning undefined so far, which is
incorrect.
In other cases it states:
Return Completion(UpdateEmpty(stmtCompletion, undefined)).
Which essentially means a statement is evaluated and its completion
value returned if non-empty, and undefined otherwise.
While not actually noticeable in normal scripts as the VM's "last value"
can't be accessed from JS code directly (with the exception of eval(),
see below), it provided an inconsistent experience in the REPL:
> if (true) 42;
42
> if (true) { 42; }
undefined
This also fixes the case where eval() would return undefined if the last
executed statement is not a value-producing one:
eval("1;;;;;")
eval("1;{}")
eval("1;var a;")
As a consequence of the changes outlined above, these now all correctly
return 1.
See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation,
"NOTE 2".
Fixes#3609.
With one small exception, this is how we've been using this API already,
and it makes sense: a Program is just a ScopeNode with any number of
statements, which are executed one by one. There's no explicit return
value at the end, only a completion value of the last value-producing
statement, which we then access using VM::last_value() if needed (e.g.
in the REPL).
Now the pixel under the cursor doesn't move, which is more consistent
with other image viewers (e.g. GwenView and IrfanView). Also switch
m_pan_origin to use window space to have less space transformations.
