This is a partial revert of commit 7af5eef. After 97d15e9, the 'proc'
promise is not needed for operations using getsid().
This also fixes launching several applications in which 7af5eef added
the 'proc' promise only in the second call to pledge().
This commit does three things atomically:
- switch over Core::Account+SystemServer+LoginServer to sid based socket
names.
- change socket names with %uid to %sid.
- add/update necessary pledges and unveils.
Userland: Switch over servers to sid based sockets
Userland: Properly pledge and unveil for sid based sockets
URL had properly named replacements for protocol(), set_protocol() and
create_with_file_protocol() already. This patch removes these function
and updates all call sites to use the functions named according to the
specification.
See https://url.spec.whatwg.org/#concept-url-scheme
This has two advantages: First the picker no longer changes the active
window state of its parent. Visually this is an additional hint that the
dialog is "fragile" and will close on loss of focus. Second, because
it contains a search box, its own input won't be preempted by global
application shortcuts when typing (pending #15129). This is a problem
in apps like PixelPaint which use shortcuts without modifiers.
Currently, LibUnicodeData contains the generated UCD and CLDR data. Move
the UCD data to the main LibUnicode library, and rename LibUnicodeData
to LibLocaleData. This is another prepatory change to migrate to
LibLocale.
And adjust some GML properties. Since a808cfa, splitters grow
opportunistically. Setting them to fixed sizes now quite literally
fixes them in place. Fixes immovable splitters missed in the
aforementioned commit.
Intrinsics, i.e. mostly constructor and prototype objects, but also
things like empty and new object shape now live on a new heap-allocated
JS::Intrinsics object, thus completing the long journey of taking all
the magic away from the global object.
This represents the Realm's [[Intrinsics]] slot in the spec and matches
its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of
architecture.
In the majority of cases it should now be possibly to fully allocate a
regular object without the global object existing, and in fact that's
what we do now - the realm is allocated before the global object, and
the intrinsics between both :^)
with the CaptureInput WindowMode. This mode will serve the same
function as accessories: redirecting input while allowing parent
windows to remain active.
The basic idea is that a global object cannot just come out of nowhere,
it must be associated to a realm - so get it from there, if needed.
This is to enforce the changes from all the previous commits by not
handing out global objects unless you actually have an initialized
realm (either stored somewhere, or the VM's current realm).
- Prefer VM::current_realm() over GlobalObject::associated_realm()
- Prefer VM::heap() over GlobalObject::heap()
- Prefer Cell::vm() over Cell::global_object()
- Prefer Wrapper::vm() over Wrapper::global_object()
- Inline Realm::global_object() calls used to access intrinsics as they
will later perform a direct lookup without going through the global
object
This is needed so that the allocated NativeFunction receives the correct
realm, usually forwarded from the Object's initialize() function, rather
than using the current realm.
Global object initialization is tightly coupled to realm creation, so
simply pass it to the function instead of relying on the non-standard
'associated realm' concept, which I'd like to remove later.
This works essentially the same way as regular Object::initialize() now.
Additionally this allows us to forward the realm to GlobalObject's
add_constructor() / initialize_constructor() helpers, so they set the
correct realm on the allocated constructor function object.
This is a continuation of the previous six commits.
The global object is only needed to return it if the execution context
stack is empty, but that doesn't seem like a useful thing to allow in
the first place - if you're not currently executing JS, and the
execution context stack is empty, there is no this value to retrieve.
This is a continuation of the previous five commits.
A first big step into the direction of no longer having to pass a realm
(or currently, a global object) trough layers upon layers of AOs!
Unlike the create() APIs we can safely assume that this is only ever
called when a running execution context and therefore current realm
exists. If not, you can always manually allocate the Error and put it in
a Completion :^)
In the spec, throw exceptions implicitly use the current realm's
intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
This is a continuation of the previous three commits.
Now that create() receives the allocating realm, we can simply forward
that to allocate(), which accounts for the majority of these changes.
Additionally, we can get rid of the realm_from_global_object() in one
place, with one more remaining in VM::throw_completion().
This is a continuation of the previous two commits.
As allocating a JS cell already primarily involves a realm instead of a
global object, and we'll need to pass one to the allocate() function
itself eventually (it's bridged via the global object right now), the
create() functions need to receive a realm as well.
The plan is for this to be the highest-level function that actually
receives a realm and passes it around, AOs on an even higher level will
use the "current realm" concept via VM::current_realm() as that's what
the spec assumes; passing around realms (or global objects, for that
matter) on higher AO levels is pointless and unlike for allocating
individual objects, which may happen outside of regular JS execution, we
don't need control over the specific realm that is being used there.
This is a continuation of the previous commit.
Calling initialize() is the first thing that's done after allocating a
cell on the JS heap - and in the common case of allocating an object,
that's where properties are assigned and intrinsics occasionally
accessed.
Since those are supposed to live on the realm eventually, this is
another step into that direction.
No functional changes - we can still very easily get to the global
object via `Realm::global_object()`. This is in preparation of moving
the intrinsics to the realm and no longer having to pass a global
object when allocating any object.
In a few (now, and many more in subsequent commits) places we get a
realm using `GlobalObject::associated_realm()`, this is intended to be
temporary. For example, create() functions will later receive the same
treatment and are passed a realm instead of a global object.
Using the fact that there are 2^52-2 NaN representations we can
"NaN-box" all the Values possible. This means that Value no longer has
an explicit "Type" but that information is now stored in the bits of a
double. This is done by "tagging" the top two bytes of the double.
For a full explanation see the large comment with asserts at the top of
Value.
We can also use the exact representation of the tags to make checking
properties like nullish, or is_cell quicker. But the largest gains are
in the fact that the size of a Value is now halved.
The SunSpider and other benchmarks have been ran to confirm that there
are no regressions in performance compared to the previous
implementation. The tests never performed worse and in some cases
performed better. But the biggest differences can be seen in memory
usage when large arrays are allocated. A simple test which allocates a
1000 arrays of size 100000 has roughly half the memory usage.
There is also space in the representations for future expansions such as
tuples and records.
To ensure that Values on the stack and registers are not lost during
garbage collection we also have to add a check to the Heap to check for
any of the cell tags and extracting the canonical form of the pointer
if it matches.
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
For some reason LibGUI sends two events for each edit, and one of them
contains an OOB cursor if a character was deleted.
This works around that for now.
This is a bit of a hack, but it is an easy way to finally get spacers
into GML.
This will translate well if spacers are later to become child objects of
the continer widget.
Also moves WebContentClient and the references to the generated IPC
descriptions, since they are all components of OutOfProcessWebView.
This patch has no functional changes.
Instead of having the undo operation only be able to undo one cell
for a given undo, make it able to handle multiple cells at a time.
Please enter the commit message for your changes. Lines starting
Previously, the paste action was always enabled and always assumed that
anything was selected, which led to a crash by clicking the paste action
right after the application startup.
This patch will automatically enable/disable the paste action depending
on whether a selection exists (it usually does, except on the app launch
and after adding a new tab) and if the clipboard mime type is a text/
group.
So no, you can't paste an image into the app anymore, even though this
mostly froze the app before...
Forgot to remove that in c0c9825f67, as
this function was no longer declared and used... Until the previous
commit.
This meant that pressing the F2 key after opening a file no longer
matched the current tab.
Besides from reusing more parts from the code, this allows us to call
the action using the F2 key. That is also the reason why we have
to reassign `m_tab_context_menu_sheet_view` on tab change.
This is useful, for instance, in games in which you can switch held
items using the scroll wheel. In order to implement this, they
previously would have to either add a hard-coded division by 4, or look
up your mouse settings to adjust correctly.
This commit adds an MouseEvent.wheel_raw_delta_x() and
MouseEvent.wheel_raw_delta_y().
These can be generated by saving something that's not serialisable (e.g.
functions), skip over them and let the load logic reevaluate them when
needed.
Take into account the current scroll position when calculating the
position of cells. This way when the user scrolls either horizontally
or vertically, the calculations done to find the cell position
will be correct.
When the drop location of a drag-and-drop operation is not valid, then
don't continue with the drop_event. For example, if the ending location
is the header row or header column, or is outside of the table, then
should not continue.
Implements ability to extend a cell's contents by clicking the bottom
right of the cell and dragging in a linear direction. For now, the
content that is extended is simply a copy of the target cell's
values.
Since copying and cutting uses the cell values in the origin to decide
which values to paste in the destination, it is necessary to do it
in an ordered manner when the origin and destination ranges overlap.
Otherwise you may overwrite values in the origin unintentionally
before having successfully transferred them to the destination.
Use cut instead of copy when dragging one or many cells' contents.
This is more intuitive as most other spreadsheet applications
handle the drag in this manner instead of as a copy operation.
When finished dragging and cutting, select the cells in the
destination. E.g. if you select 5 cells and drag and paste
them in a new location, select the 5 pasted cells in the
destination.
Due to the fact that in the AbstractView, when multiple cells are
selected, and then another cell is selected within this selection,
the cursor is not updated as the user may be beginning to drag, have
to override this functionality for the Spreadsheet application.
This is because in spreadsheets when multiple cells are selected,
and then you click on one of the cells within the selection,
the selection should be cleared and the targetted cell highlighted.
Due to the margin that is given to be able to select cells for
cutting or extending, have to override the mouse click function
so that the targetted cell is chosen and not the one that may be
beneath the cursor.
Depending on the cursor location with respect to a selected cell,
display different icons pertaining to the distinct possible actions,
for example dragging and cutting, extending the cell's contents, or
doing a simple selection.
It makes no sense to require passing a global object and doing a stack
space check in some cases where running out of stack is highly unlikely,
we can't recover from errors, and currently ignore the result anyway.
This is most commonly in constructors and when setting things up, rather
than regular function calls.
Previously, we were setting tab actions only for the active tab on a tab
change, and the same actions for the previous tab were removed.
Unfortunately, this also happened when making a new tab, which meant
that you could trick the cell editor to jump to the new sheet and start
writing there.
To fix this, every view will always have on_selection_changed
and on_selection_dropped assigned. I haven't seen much difference in
the memory usage, so I guess it'll be fine :)
NumericCell::display() attempted to take a substring of cell contents
according to the "Override max length" parameter,
but it did not account for the actual string length.
The previous code never executed, as SpreadsheetView splits selection
events into `on_selection_changed` and `on_selection_dropped` depending
on whether there is any selection.
Prior to this commit, there was a set_filename() function that could set
the window title, but actually it never did that. It was called only
in one place -- by the 'Save as...' action, but it always failed to
change anything, because there was a check that tried to reassign
the same filename. :/
This patch:
1. removes that check, and therefore
2. renames the function to simply `update_window_title()`,
3. starts calling the function from more places (at startup and after
loading a file),
4. changes the window title order
(`{app_name} - {filename}` -> `{filename} - {app_name}`) to match
the other applications style on the system. :^)
Up until now, the Spreadsheet function examples appeared below their
descriptions. Let's swap them to make it clearer which JS example
goes to which description.
The Spreadsheet application currently does not support undo/redo,
and with this update, we are starting the process of adding this feature
:-)
Additionally, the save dialog has been updated to use
GUI::MessageBox::ask_about_unsaved_changes() for system cohesity.
Spreadsheet: Add basic undo functinoality
The spreadsheet application now has basic support for undo. Testing of
this feature is limited, and may not work as intended yet.
Spreadsheet: Add callback when a cell's value is changed
In addition to the callback being added, this commit also exposes the
SheetModel class via a getter in SpreadSheetView.
Spreadsheet: Remove debug statements and use cell change callback
This commit uses the on_cell_data_change callback from within the
SheetModel class. This allows for us to push/pop changes to the undo
stack.
With this, we have basic Undo/Redo functionality :-)
Spreadsheet: Actually add window::set_modified
Spreadsheet: Const-correctness :-)
Spreadsheet: Reorder the edit menu actions
Now that the GML formatter is both perserving comments and also mostly
agrees to the existing GML style, it can be used to auto-format all the
GML files in the system. This commit does not only contain the scripts
for running the formatting on CI and the pre-commit hook, but also
initially formats all the existing GML files so that the hook is
successfull.
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
This has some risks as it can (attempt to) load arbitrary files on the
filesystem but for now it can only load local files which do go through
normal file operations. But let's enable it for now to see what we can
do with it.
This also refactors interpreter creation to follow
InitializeHostDefinedRealm, but I couldn't fit it in the title :^)
This allows us to follow the spec much more closely rather than being
completely ad-hoc with just the parse node instead of having all the
surrounding data such as the realm of the parse node.
The interpreter creation refactor creates the global execution context
once and doesn't take it off the stack. This allows LibWeb to take the
global execution context and manually handle it, following the HTML
spec. The HTML spec calls this the "realm execution context" of the
environment settings object.
It also allows us to specify the globalThis type, as it can be
different from the global object type. For example, on the web, Window
global objects use a WindowProxy global this value to enforce the same
origin policy on operations like [[GetOwnProperty]].
Finally, it allows us to directly call Program::execute in perform_eval
and perform_shadow_realm_eval as this moves
global_declaration_instantiation into Interpreter::run
(ScriptEvaluation) as per the spec.
Note that this doesn't evalulate Source Text Modules yet or refactor
the bytecode interpreter, that's work for future us :^)
This patch was originally build by Luke for the environment settings
object change but was also needed for modules. So I (davidot) have
modified it with the new completion changes and setup for that.
Co-authored-by: davidot <davidot@serenityos.org>
The point of a reference type is to behave just like the referred-to
type. So, a Foo& should behave just like a Foo.
In these cases, we had a const Vector. If it was a const Vector of Foo,
iterating over the Vector would only permit taking const references to
the individual Foos.
However, we had a const Vector of Foo&. The behavior should not
change. We should still only be permitted to take const references to
the individual Foos. Otherwise, we would be allowed to mutate the
individual Foos, which would mutate the elements of the const Vector.
This wouldn't modify the stored pointers, but it would modify the
objects that the references refer to. Since references should be
transparent, this should not be legal.
So it should be impossible to get mutable references into a const
Vector. Since we need mutable references in these cases to call the
mutating member functions, we need to mark the Vector as mutable as
well.
Change the parent of the WizardDialog to that of the Spreadsheet window.
Previously the WizardDialog was using the open file dialog as the
parent resulting in the csv import dialog
Instead of making it a void function, checking for an exception, and
then receiving the relevant result via VM::last_value(), we can
consolidate all of this by using completions.
This allows us to remove more uses of VM::exception(), and all uses of
VM::last_value().
In the end this is a nicer API than having separate has_{value,target}()
and having to check those first, and then making another Optional from
the unwrapped value:
completion.has_value() ? completion.value() : Optional<Value> {}
// ^^^^^^^^^^^^^^^^^^
// Implicit creation of non-empty Optional<Value>
This way we need to unwrap the optional ourselves, but can easily pass
it to something else as well.
This is in anticipation of the AST using completions :^)
When selecting a cell in the spreadsheet that was added
automatically as per the InfinitelyScrollableTableView
implementation, the background color is now filled correctly.
Previously, when navigating horizontally in a spreadsheet, after
a certain point the cells would not have the same background fill
color as the user would have experienced in the previous column
ranges (A-Z).
This is partially a revert of commits:
10a8b6d411561b67a1ad
Rather than adding the prot_exec pledge requried to use dlopen(), we can
link directly against LibUnicodeData in applications that we know need
that library.
This might make the dlopen() dance a bit unnecessary. The same purpose
might now be fulfilled with weak symbols. That can be revisted next, but
for now, this at least removes the potential security risk of apps like
the Browser having prot_exec privileges.
Loading libunicodedata.so will require dlopen(), which in turn requires
mmap(). The 'prot_exec' pledge is needed for this.
Further, the .so itself must be unveiled for reading. The "real" path is
unveiled (libunicodedata.so.serenity) as the symlink (libunicodedata.so)
itself cannot be unveiled.
Cell::set_data(String new_data) now checks whether the cell is a
formula-cell and the new_data is an empty string. If this is case, it
will no longer simply return and will now instead actually set the
cell's contents to an empty string.
This fixes an error whereupon committing the string "=" to a cell, it
would not be possible to directly delete the cell's contents. Instead,
it first had to be overwritten with another string, which then could be
deleted.
This could probably be done more elegantly. Right now, I believe,
writing the string "=" to a (formula-)cell already containing an
identical string will result in the cell being marked as dirty, even
though nothing actually changed.
We should use .to_string() and handle the possible exceptions.
This makes the displayed cell contents so much more informative than
'[object Object]' :^)
Now we give each sheet its own interpreter and realm, and only make them
share the VM.
This is to prepare for the next commit, which will be refactoring a
bunch of things to propagate exceptions via ThrowCompletionOr<T>.
The worksheet's realm does not change, and is not shared, so we can
safely leave the global environment be.
This fixes lexical scoping in the spreadsheet's runtime file.
Also add slightly richer parse errors now that we can include a string
literal with returned errors.
This will allow us to use TRY() when working with JSON data.
The old versions were renamed to JS_DECLARE_OLD_NATIVE_FUNCTION and
JS_DEFINE_OLD_NATIVE_FUNCTION, and will be eventually removed once all
native functions were converted to the new format.
