When clicking on a window's frame that is blocked by a modal
window, we want to bring the entire window stack to the front
regardless of where the user clicked in the frame (not just the
icon).
Allow passing in an optional timeout to Thread::block and move
the timeout check out of Thread::Blocker. This way all Blockers
implicitly support timeouts and don't need to implement it
themselves. Do however allow them to override timeouts (e.g.
for sockets).
When waiting for a specific message, only consider messages
from the peer endpoint. Otherwise a message with the same id
for the local endpoint may be misinterpreted.
This fixes the Terminal sometimes hanging after bootup because
a local endpoint message is mistaken for the CreateMenuResponse
message.
We need to have a Thread lock to protect threading related
operations, such as Thread::m_blocker which is used in
Thread::block.
Also, if a Thread::Blocker indicates that it should be
unblocking immediately, don't actually block the Thread
and instead return immediately in Thread::block.
Also change DOM::Document::document_element() to return an Element*
and not an HTML::HTMLHtmlElement since that's not the only kind of
documentElement we might encounter.
HTMLElement is the only interface that includes ElementContentEditable
in the HTML specification. This makes sense, as Element is also a base
class for elements in other specifications such as SVG,
which definitely shouldn't be editable.
Also adds a test for the attribute based on what Andreas did in the
video that added it.
I noticed on boot, WindowServer was getting an veil error:
[WindowServer(13:13)]: Rejecting path '/res/themes/Default.ini' since it hasn't been unveiled with 'c' permission.
[WindowServer(13:13)]: 0xc014367f _ZN6Kernel3VFS34validate_path_against_process_veilEN2AK10StringViewEi +681
[WindowServer(13:13)]: 0xc01439d7 _ZN6Kernel3VFS12resolve_pathEN2AK10StringViewERNS_7CustodyEPNS1_6RefPtrIS3_EEii +163
[WindowServer(13:13)]: 0xc0143d03 _ZN6Kernel3VFS4openEN2AK10StringViewEitRNS_7CustodyENS1_8OptionalINS_9UidAndGidEEE +121
[WindowServer(13:13)]: 0xc016fbc4 _ZN6Kernel7Process8sys$openEPKNS_7Syscall14SC_open_paramsE +854
[WindowServer(13:13)]: 0xc0164af8 syscall_handler +1320
[WindowServer(13:13)]: 0xc0164541 syscall_asm_entry +49
[WindowServer(13:13)]: 0x08097ca0 open_with_path_length +24
[WindowServer(13:13)]: 0x08097cf8 open +63
[WindowServer(13:13)]: 0x080a3c59 fopen +31
[WindowServer(13:13)]: 0x0806abf0 _ZN4Core10ConfigFile4syncEv +48
[WindowServer(13:13)]: 0x0806af6a _ZN4Core10ConfigFileD2Ev +16
[WindowServer(13:13)]: 0x08093e2a _ZN3Gfx17load_system_themeERKN2AK6StringE +1869
[WindowServer(13:13)]: 0x08048633 main +491
[WindowServer(13:13)]: 0x08048dae _start +94
With some digging I found out that the ConfigFile class was causing
trying to flush writes of default values, not present in the .ini
file back to disk on destruction of the object.
This sneaky behavior from ConfigFile seems to violate the public facing
semantics of the function (it's const). It also makes it very hard to reason
about the system with technologies like unveil where we are trying to
explicitly state what is exposed to apps, how those exposed items can be
used.
The functionality also doesn't seem to be all that useful, as we'll just
return the default value from the API's anyway.
This change removes the write back of default values.
This fixes a regression introduced by the new software context
switching where the Kernel would not deliver a signal unless the
process is making system calls. This is because the TSS no longer
updates the CS value, so the scheduler never considered delivery
as the process always appeared to be in kernel mode. With software
context switching we can just set up the signal trampoline at
any time and when the processor returns back to user mode it'll
get executed. This should fix e.g. killing programs that are
stuck in some tight loop that doesn't make any system calls and
is only pre-empted by the timer interrupt.
Fixes#2958
Breakpoints need to be disabled before we detach from the debugee.
I noticed this while looking into the fact that if you continue
executing a program in sdb (/bin/ls) where you had previously
set a breakpoint, it would crash on sdb exit once the debugee died
with an assert on HashMap destruction where we were iterating
while clearing is set. This change also happens to fix this assert.
- parse_flag now only parses one digit instead of consuming an entirely
valid number
- match_number => match_coordinate
- match_coordinate now returns true if `ch()` is '.'
- parse_number no longer matches a +/-
- Don't crash when encountering one of the three unsupported path
commands. Instead, just skip them. No reason to crash the browser over a
silly SVG element :)
./configure generates about 3500 lines in a few seconds. Noone will ever read
those lines and they make loading the Travis webpage slower. And if there is
ever a problem, it will be because the Travis base image changed (which happens
only rarely) in a way that interferes with compiling gcc (which is incredibly
unlikely), or we update gcc (which happens very rarely) and gcc doesn't like
the Travis iamge (which again is incredibly unlikely). In all of these cases,
finding the culprit will be self-evident.
This works everywhere right now, but it's obviously not going to stay
that way forever. :^)
Note that this does not advance the cursor correctly for whitespace
since the cursor is DOM-based and doesn't take whitespace collapsing
into account yet.
Each Web::Frame now has a cursor that sits at a DOM::Position. It will
blink and look like a nice regular text cursor.
It doesn't really do anything yet, but it will eventually.
By making the Process class RefCounted we don't really need
ProcessInspectionHandle anymore. This also fixes some race
conditions where a Process may be deleted while still being
used by ProcFS.
Also make sure to acquire the Process' lock when accessing
regions.
Last but not least, there's no reason why a thread can't be
scheduled while being inspected, though in practice it won't
happen anyway because the scheduler lock is held at the same
time.
Upon leaving a critical section (such as a SpinLock) we need to
check if we're already asynchronously invoking the Scheduler.
Otherwise we might end up triggering another context switch
as soon as leaving the scheduler lock.
Fixes#2883
This is a very cheesy patch and I don't like it, but as Qt Creator does
not grok C++20 concepts yet, this makes it possible to still use syntax
highlighting.
We'll remove this hack the moment it stops being a problem. Note that
it doesn't actually affect the build since we use GCC, not Clang.
