This includes:
- Parsing proper LabelledStatements with try_parse_labelled_statement()
- Removing LabelableStatement
- Implementing the LoopEvaluation semantics via loop_evaluation() in
each IterationStatement subclass; and IterationStatement evaluation
via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute()
- Updating ReturnStatement, BreakStatement and ContinueStatement to
return the appropriate completion types
- Basically reimplementing TryStatement and SwitchStatement according to
the spec, using completions
- Honoring result completion types in AsyncBlockStart and
OrdinaryCallEvaluateBody
- Removing any uses of the VM unwind mechanism - most importantly,
VM::throw_exception() now exclusively sets an exception and no longer
triggers any unwinding mechanism.
However, we already did a good job updating all of LibWeb and userland
applications to not use it, and the few remaining uses elsewhere don't
rely on unwinding AFAICT.
Instead of slapping 0..N labels on a statement like the current
LabelableStatement does, we need the spec's LabelledStatement for a
proper implementation of control flow using only completions - it always
has one label and one labelled statement - what appears to be 'multiple
labels' on the same statement is actually nested LabelledStatements.
Note that this is unused yet and will fully replace LabelableStatement
in the next commit.
Sometimes, pumping the event loop will cause new events to be
generated. For example, an IPC message could be delivered which then
dispatches a new event to be handled by the GUI. To the invoker of
`EventLoop::pump()`, it is not obvious if any events were processed at
all.
Libraries like SDL2 might not have the opportunity to run the event
loop often enough that events can be processed swiftly, since it might
spend time doing other things. This can result in stuttering GUI
interactions.
This changes `EventLoop::pump()` to return the number of processed
events. This functionality will be used by our SDL2 port in another PR.
Previously, only terminal output aligned table column contents
correctly. Now, we apply a `text-align` to each cell. This does not
actually *work* however, since LibWeb's table layout code is not yet
fully functional.
This fixes all failing Date.UTC test262 tests, which failed due to not
handling invalid input and evaluating inputs out of order. But this also
avoids using timegm(), which doesn't work on macOS for years before 1900
(they simply return -1 for those years).
Partially addresses #4651. Date.parse.js still fails.
We currently use Core::DateTime create, which internally uses mktime().
This has the issues pointed out by the (now removed) FIXME, but also has
an issue on macOS where years before 1900 are not supported.
When searching for the locale-specific flexible day period for a given
hour, we were neglecting to handle cases where the period crosses 00:00.
For example, the en locale defines a day period range of [21:00, 06:00).
When given the hour of 05:00, we were checking if (21 <= 5 && 5 < 6),
thus not recognizing that the hour falls in that period.
This impacts text editors' ctrl+left, ctrl+shift+right, ctrl+backspace,
etc..
For example, consider the text "Hello world |", pressing
ctrl+backspace each time.
Before: "hello world |"
"hello world|"
"hello |"
"hello|"
"|"
After: "hello world |"
"hello|"
"|"
Note that this breaks a nice symmetry. Doing ctrl+left and then
ctrl+right doesn't necessarily get you to the same place like it use to.
Before: " hello |"
" hello| "
" hello |" // same as initial
After: " hello |"
"|hello "
" hello| " // different from initial
In preparation for making Vector::append + Vector::prepend
unavailable during compilation of the Kernel.
This specific file is compiled into the Kernel as well as LibVT.
This is just a slight variation of `/res/icons/16x16/paste.png`, I've
removed the lines on the paper to make it look consistent with the
"New Image" icon, which is an empty piece of paper.
I think this is likely the more common operation and makes more sense
in the toolbar. It calls the 'save as' action internally anyway if there
is no associated file.
Now, when trying to close the application, there is a separate prompt
for each open tab with unsaved changes. Each tab is closed after it is
handled appropriately (assuming the user didn't Cancel), this makes it
so that the message box is always asking about the currently active tab,
allowing the user to see that the image contains.
If at any point the user presses "Cancel", all remaining tabs are kept
open.
Previously MainWidget::request_close() would always put up the
message box asking to save unsaved changes, even if there aren't any.
This patch makes it so that the message box is only shown if the
undo stack is in a modified state.
As noted in the latest hacking video, it doesn't seem to make much
sense to store the title and path in the image itself. These fields
have now been moved to the actual ImageEditor itself.
This allows some nice simplicfications, including getting rid of the
`image_did_change_title` hook of ImageClient (which was just a way to
report back to the editor that the title had changed).
This allows you to keep an arbitrary JS::Value alive without having to
hook visit_edges somewhere, e.g. by being a NativeFunction that
overrides visit_edges.
For example, this allows you to store JS::Handle<JS::Value> as the key
of a HashMap. This will be used to keep arbitrary Values alive in
the key of a temporary HashMap in Array.prototype.groupByToMap.
Co-authored-by: Ali Mohammad Pur <mpfard@serenityos.org>
In one case we can replace it with MUST() and accept the crash (we also
VERIFY() that there wasn't an exception); in the other case we don't
need to return after a throw completion.
Currently, we load the generated Unicode symbols with dlopen at runtime.
This is unnecessary as of 565a880ce5.
Applications that want Unicode data now link directly against the shared
library holding that data. So the same functionality can be achieved
with weak symbols.
This requires an implementation of the "text preparation algorithm" as
specified here:
html.spec.whatwg.org/multipage/canvas.html#text-preparation-algorithm
However, we're missing a lot of things such as the
CanvasTextDrawingStyles interface, so most of the algorithm was not
implemented. Additionally, we also are not able to use a LineBox like
the algorithm suggests, because our layouting infra is not up to the
task yet. The prepare_text function does nothing other than figuring out
the width of the given text and return glyphs with offsets at the
moment.
