| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit f102b563
The reverted to behavior is not correct for example with a double proxy
But this change lead to problems with DOMNodes
|
|
If we define a property with just a setter/getter (not both) we must:
- take the previous getter/setter if defined on the actual object
- overwrite the other to nullptr if it is from a prototype
|
|
Before this it would always go through the native setter thus
modifying the array but now you can set length to anything
|
|
|
|
|
|
|
|
|
|
Fixes regressed with 0f9038b732a6e0f5830e5e95c0b2a1c78efea415.
|
|
This patch adds support for the NumericLiteralSeparator concept from
the ECMAScript grammar.
|
|
|
|
This should help reduce the random test failures due to timeouts on
slower github actions runners.
|
|
|
|
|
|
|
|
ArrayIteratorPrototype::next seems to implement CreateArrayIterator,
which is an issue for a separate PR.
|
|
According to the gcc man page these are mutually exclusive and did
in fact cause problems when trying to get the address for asm labels
on x86_64.
|
|
The types for asm_signal_trampoline and asm_signal_trampoline_end
were incorrect. They both point into the text segment but they're
not really functions.
|
|
This isn't particularly useful because by the time we've entered
init() the CPU had better support x86_64 anyway. However this shows the
CPU flag in System Monitor - even in 32-bit mode.
|
|
Without this the ProcessBase class is placed into the padding for the
ProtectedProcessBase class which then causes the members of the
RefCounted class to end up without the first 4096 bytes of the Process
class:
BP 1, Kernel::Process::protect_data (this=this@entry=0xc063b000)
205 {
(gdb) p &m_ref_count
$1 = (AK::Atomic<unsigned int, (AK::MemoryOrder)5> *) 0xc063bffc
Note how the difference between 'this' and &m_ref_count is less than
4096.
|
|
|
|
|
|
|
|
Those size_ts sure are growing up fast.
|
|
Our types are getting a tiny bit larger for x86_64 so we need another
slab allocator to deal with that.
|
|
|
|
|
|
The GDT limits are inclusive, so for correctness we should subtract
one from the structs' size.
|
|
In the spec, object environments have a [[BindingObject]], so let's
call it the same thing in our implementation.
|
|
We already store the GlobalObject& in a base class, so no need to also
store it in the subclass. :^)
|
|
Also make use of OrdinaryCreateFromConstructor() instead of setting
the prototype manually.
This fixes 2 function tests in test262. :^)
|
|
QEMU appears to always relay absolute mouse coordinates relative to the
screen that the mouse is pointed to, without any way for us to know
what screen it was. So, when dealing with multiple displays force using
relative coordinates only.
|
|
Negative numeric properties are not a thing (and we even VERIFY()'d this
in the constructor). It still allows using types with a negative range
for now as we have various places using int for example (without
actually needing the negative range, but that's a different story).
u32 is the internal type of `m_number` already, so this now allows us to
leverage the full u32 range for numeric properties.
|
|
Requires a bunch of find-and-replace updates across LibJS, but
constructing a PropertyName from a nullptr Symbol* should not be
possible - let's enforce this at the compiler level instead of using
VERIFY() (and already dereference Symbol pointers at the call site).
|
|
This allows specifying how many screens we should use. This also then
only enables virtio-gpu if more than one display is requested.
This also adds an environment variable SERENITY_QEMU_DISPLAY_BACKEND
which allows overriding the default qemu display backend, as it may
not be available.
|
|
This is for the [[Environment]] slot so let's have a matching name. :^)
|
|
This is not a behavioral change in itself, just prep work for future
spec-compliance changes.
|
|
We were setting the wrong [[FunctionObject]] on the environment when
going through ProxyObject and BoundFunction.
|
|
This matches what the spec calls them.
|
|
|
|
This enables flicker-free rendering.
|
|
This enables flicker-free rendering.
|
|
This will be helpful once we allow the user to rearrange the displays.
|
|
An Overlay is similar to a transparent window, but has less overhead
and does not get rendered within the window stack. Basically, the area
that an Overlay occupies forces transparency rendering for any window
underneath, which allows us to render them flicker-free.
This also adds a new API that allows displaying the screen numbers,
e.g. while the user configures the screen layout in DisplaySettings
Because other things like drag&drop or the window-size label are not
yet converted to use this new mechanism, they will be drawn over the
screen-number currently.
|
|
If the shadow bitmap contains portions of the frame then we need to
slightly tweak the logic dealing with very small width and/or height.
|
|
|
|
Instead of calling clear() for each virtual console we initialize, we
only call clear() when activating it from ConsoleManagement.
|
|
|
|
|
|
|
|
|
