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.
This patch makes tgamma use an approximation that is more accurate with
regards to floating point arithmetic, and fixes some issues when tgamma
was called with positive integer values.
It also makes lgamma set signgam to the correct value, and makes its
return value be more inline with what the C standard defines.
This ensures that when a DeflateCompressor stream is cleared of any
errors its underlying wrapped streams (InputBitStream/InputMemoryStream)
will be cleared as well and wont fail a VERIFY on destruction.
In case multiple file descriptors in the `fd_set` were already readable
and/or writable when calling Thread::block<SelectBlocker>(), we would
only mark the first fd in the output sets instead of all relevant fd's.
The short-circuit code path when blocking isn't necessary must ensure
that unblock flags are collected for all file descriptors, not just the
first one encountered.
Fixes#5795.
There's a bit more nuance to how this should really work, but let's at
least make sure we execute <script> elements if you insert them into
the document.
Use the new CustomGet/CustomPut wrapper mechansim to intercept gets and
puts on CSSStyleDeclaration objects. This allows content to get and set
individual CSS properties from JavaScript. :^)
You can now set the CustomGet and/or CustomPut extended attributes on
an interface. This allows you to override JS::Object::get/put in the
wrapper class.
This small commit should allow to specify additionnal parameters in the
form of URL queries, when opening a file via a "file://" url through the
LaunchServer.
