Age | Commit message (Collapse) | Author |
|
If you try to do this (e.g "mv directory directory"), sys$rename() will
now fail with EDIRINTOSELF.
Dr. POSIX says we should return EINVAL for this, but a custom error
code allows us to print a much more helpful error message when this
problem occurs. :^)
|
|
If a PD/PT was quick-mapped by another CPU we still need to flush the
TLB on the current CPU.
Fixes #3885
|
|
Now when opening the project a search will be made for
a file with the extension cpp or js and opening it.
If not found, the first file will be opened.
|
|
|
|
|
|
Otherwise, we'll end up overwriting another frame's variables if the
names match up.
|
|
As Vector<T> will relocate objects to resize, we cannot assume that the
address of a specific LocalFrame will stay constant, or that the
reference will not be dangling to begin with.
Fixes an assertion that fires when a frame push causes the Vector to
reallocate.
|
|
Views would previously require that an item be selected before it could
be dragged. This patch makes us consider initiating a drag immediately
after the view has been selected, without requiring a mouseup event in
between.
|
|
|
|
This is sad (since it would be nice to preserve the cursor+selection)
but until we implement persistent model indexes, this at least prevents
us from keeping a stale cursor index.
|
|
|
|
|
|
|
|
Remapping these registers every time we try to read from or write to
them causes a lot of SMP broadcasts and a lot of other overhead.
This improves boot time noticeably.
|
|
|
|
|
|
|
|
`DOM::XMLHttpRequest` now checks if the requested URL has the same
`Origin` as the requesting `Document`. If the requested URL is in
violation of SOP the request is rejected and an "error" `DOM::Event`
is dispatched.
|
|
We just call the early helpers as they do the same thing like the IO
access helpers.
|
|
Instead of mapping a 4KB region to access device configuration space
each time we call one of the PCI helpers, just map them once during
the boot process.
Then, if we request to access one of those devices, we can ask the
PCI subsystem to give us the virtual address where the device's
configuration space is mapped.
|
|
|
|
|
|
Base/res/fonts/CsillaThin7x10.font was renamed to
Base/res/fonts/CsillaRegular10.font in 5abc03d, breaking the default
styles of <code> and <pre>.
The font lookup should still find a font variant when a non-existent
weight is specified, but that's another issue for another day.
|
|
The previous approach (keeping track of the current source position
manually) was only working for single line sources (which is fair
considering this was developed for Browser's JS console).
The new approach is much simpler: append token trivia (all whitespace
and comments since the last token), then append styled token value.
|
|
|
|
Now the functions can actually be demonstrated by small examples,
embedded right inside the documentation via:
spreadsheet://example/<page>#<example_name>
Also allows pages to link to each other via the same scheme:
spreadsheet://doc/<page>
|
|
https://tc39.es/ecma262/#sec-functiondeclarations-in-ifstatement-statement-clauses
B.3.4 FunctionDeclarations in IfStatement Statement Clauses
The following augments the IfStatement production in 13.6:
IfStatement[Yield, Await, Return] :
if ( Expression[+In, ?Yield, ?Await] ) FunctionDeclaration[?Yield, ?Await, ~Default] else Statement[?Yield, ?Await, ?Return]
if ( Expression[+In, ?Yield, ?Await] ) Statement[?Yield, ?Await, ?Return] else FunctionDeclaration[?Yield, ?Await, ~Default]
if ( Expression[+In, ?Yield, ?Await] ) FunctionDeclaration[?Yield, ?Await, ~Default] else FunctionDeclaration[?Yield, ?Await, ~Default]
if ( Expression[+In, ?Yield, ?Await] ) FunctionDeclaration[?Yield, ?Await, ~Default]
This production only applies when parsing non-strict code. Code matching
this production is processed as if each matching occurrence of
FunctionDeclaration[?Yield, ?Await, ~Default] was the sole
StatementListItem of a BlockStatement occupying that position in the
source code. The semantics of such a synthetic BlockStatement includes
the web legacy compatibility semantics specified in B.3.3.
|
|
|
|
We were stripping the L3 headers from packets received on raw sockets.
This didn't match what other systems do, so let's adjust our behavior.
Thanks to @SpencerCDixon for noticing this! :^)
|
|
Not sure why I put this into LibGUI in the first place.
|
|
|
|
|
|
This will help us identify which View that we are currently looking at.
|
|
The calls to set_cursor() already take care of scrolling the new cursor
into view if needed.
|
|
|
|
Now we (almost) verify all the sites we browse.
Certificate verification failures should not be unexpected, as the
existing CA certificates are likely not complete.
|
|
Also adds a very primitive systemwide ca_certs.ini file.
|
|
|
|
This needs to be read out if we want to actually verify the cert chain.
|
|
|
|
This API is only used for HttpRequest, but replicated in GeminiRequest
without an actual user, so remove it and construct the job like the rest
of the protocols.
|
|
This returns true if the widget has focus, or if one of its descendant
widgets does. Use this in StackWidget and TabWidget.
This also fixes HackStudio crashing on startup in StackWidget, due to
running before the window has a focused widget.
|
|
When setting a new active widget, transfer focus if it's anywhere in
the old active widget's tree, not just at the immediate child.
|
|
When computing the chain of focusable widgets in a window, only include
each widget once (to avoid loops) and resolve focus proxies immediately
instead of lazily. This prevents the focus from getting stuck when
cycling backwards and hitting a proxy that points forward.
|
|
|
|
When opening a new window, we'll now try to find a suitable widget for
initial focus by picking the first available mouse-focusable one.
Whenever you press the tab key in a window with no focused widget,
we'll attempt to find a keyboard-focusable widget and give it focus.
This should make all applications keyboard-interactive immediately
without having to manually place focus with the mouse.
|
|
|
|
If a button is orphaned, there are no siblings anyway, so there's no
need to try to update them.
|
|
If there are no tab buttons or tab children, don't participate in the
focus chain.
|
|
This one is a bit sketchy. While a window is inactive, none of its
widgets are considered focused (Widget::is_focused() will return false)
but this caused programmatic changes of the active widget in a tab
or stack widget to fail focus propagation from old child to new child.
Work around this by checking against Window::focused_widget() directly
instead of asking Widget::is_focused().
|