The this value is only supposed to be set via the BindThisValue and
accessed via the GetThisBinding AOs, so exposing a direct getter/setter
would only lead to potentially non-spec-compliant behavior down the
line.
This patch returns an empty Optional<...> instead of an Error for
Core::System::getgrname and Core::System::getpwnam if we can't find a
matching group or user entry.
It also updates the 'chown' utility to support this new behavior.
Addresses an issue in which a window resize event after history
overflow would cause the Terminal to crash due to a failed assertion.
The problematic assertion was removed and the logic updated to
support inserting lines even when the start of the history is at an
offset (due to an overflow).
Resolves#10987
Implement a mechanism that allows us to alter colors so that they
mimic those a colorblind person would see. From the color we can then
alter the colors for the whole preview so we can simulate everything
in the theme including icons/decorations.
This filter is also available as a Filter in LibGfx so it can be
reused in multiple other places.
The color simulation algorithm is based on this one
https://github.com/MaPePeR/jsColorblindSimulator publicly available.
...for now - the reason being that the AST breaks 'completion bubbling'
and returns a plain Value, and code at the call site relies on the VM
having an exception set when converting the plain value back into a
completion.
Fixes#11301.
Much like the existing in6addr_any global and the IN6ADDR_ANY_INIT
macro, our LibC is also expected to export the in6addr_loopback global
and the IN6ADDR_LOOPBACK_INIT constant.
These were found by the stress-ng port.
These POSIX APIs are defined as mapping directly to
`strrchr` and `strchr` respectively.
These are needed for the latest version of the stress-ng port,
and also give us better POSIX compliance.
This means we can get rid of the hacks where we were peeking a code
point instead of getting the next one so that we could peek_twin()
later. Now, we follow the spec more closely. :^)
This fixes the crash that Luke found using Domato:
```css
. foo {
mso-border-alt: solid .-1pt;
}
```
The spec distinguishes between "If the next 3 code points would
start..." and "If the input stream starts with..." but we were treating
them the same way, skipping the first code point in the process.
These correspond to "If the input stream starts with..." in the spec,
which up until now we were not handling correctly, which led to some fun
bugs.
As noted, reconsuming the input code point in order to read its value is
hacky, but works. Keeping track of the current code point in Tokenizer
would be nicer, when I'm feeling brave enough to mess with it!
These are all pretty simple so I thought I would add them all in one go:
- socket()
- bind()
- listen()
- accept()
- accept4()
- connect()
- shutdown()
- send()
- sendmsg()
- sendto()
- recv()
- recvmsg()
- recvfrom()
- getsockopt()
- setsockopt()
- getsockname()
- getpeername()
- socketpair()
This implements:
- console.group()
- console.groupCollapsed()
- console.groupEnd()
In the Browser, we use `<details>` for the groups, which is not actually
implemented yet, so groups are always open.
In the REPL, groups are non-interactive, but still indent any output.
This looks weird since the console prompt and return values remain on
the far left, but this matches what Node does so it's probably fine. :^)
I expect `console.group()` is not used much outside of browsers.
The spec very kindly defines `Printer` as accepting
"Implementation-specific representations of printable things such as a
stack trace or group." for the `args`. We make use of that here by
passing the `Trace` itself to `Printer`, instead of having to produce a
representation of the stack trace in advance and then pass that to
`Printer`. That both avoids the hassle of tracking whether the data has
been html-encoded or not, and means clients don't have to implement the
whole `trace()` algorithm, but only the code needed to output the trace.
The `CountReset` log level is displayed as a warning, since the message
is always to warn that the counter doesn't exist. This is also in line
with the table at https://console.spec.whatwg.org/#loglevel-severity
This implements the Logger and Printer abstract operations defined in
the console spec, and stubs out the Formatter AO. These are then used
for the "output a categorized log message" functions.
This will allow us to easily add copies of the relevant canvas drawing
state to a stack, and likewise replace the current drawing state with
an entry from that stack.
I don't know if the original author simply missed this or thought the
default color of Gfx::Color is black, but this meant that drawing on a
canvas without explicitly setting a fillStyle or strokeStyle first would
be drawn in transparent color and therefore be invisible.
In the spec this is indicated by a small comment in the IDL definition:
attribute ... strokeStyle; // (default black)
attribute ... fillStyle; // (default black)
I'm starting to question whether Gfx::Color actually *should* have a
default constructor.
According to the Khronos FAQ on texture edge sampling, the `GL_CLAMP`
option was never implemented in hardware and as such, it was
deprecated. A lot of applications and games depend on `GL_CLAMP` not
really meaning `GL_CLAMP` but `GL_CLAMP_TO_EDGE`, so we introduce an
option to toggle this behavior at compile-time.
These stubs are largely implemented the same: their API is exposed, but
they print to the debug console and sometimes `TODO()`. These changes
allow GLU and Tux Racer to build.
Methods stubbed:
* `glTexImage1D`
* `glTexImage3D`
* `glTexCoord2d(v)`
* `glNormalPointer`
* `glTexGen(d|f|i)`
* `glTexGenfv`
According to the documentation, we should switch around vertices every
other triangle to prevent front-face culling from removing them.
This allows Tux in Tux Racer to render correctly.
Previously, if the client supplied `GL_STENCIL_BUFFER_BIT`, `glClear`
would return an error. Since it is a valid parameter, we now continue
and report that this parameter is unimplemented instead.
