The LexicalPath instance methods dirname(), basename(), title() and
extension() will be changed to return StringView const& in a further
commit. Due to this, users creating temporary LexicalPath objects just
to call one of those getters will recieve a StringView const& pointing
to a possible freed buffer.
To avoid this, static methods for those APIs have been added, which will
return a String by value to avoid those problems. All cases where
temporary LexicalPath objects have been used as described above haven
been changed to use the static APIs.
Since this is always set to true on the non-default constructor and
subsequently never modified, it is somewhat pointless. Furthermore,
there are arguably no invalid relative paths.
There is a check in map_bus_region to make sure we don't pointlessly
remap the bus region if the previous mapping was for the same bus.
This is tracked with `m_mapped_bus`.
However, nothing was actually updating `m_mapped_bus`, and it is
initialised to 0. This means that if we start with a device on bus 0,
the read in data will be valid. If we map say bus 1 then bus 0 again,
the map for bus 0 will now be ignored and invalid data will be read in.
Fixed by updating `m_mapped_bus` with the currently mapped bus.
This patch adds a PasswordBox. At the moment, it's simply a TextBox with
it's substitution code point set to '*', and the undo and redo actions
disabled.
This patch adds the member variable m_substitution_code_point to
GUI::TextEditor. If non-zero, all gylphs to be drawn will be substituted
with the specified code point. This is mainly needed to support a
PasswordBox.
While the primary use-case is for single-line editors, multi-line
editors are also supported.
To prevent repeated String construction, a m_substitution_string_data
members has been added, which is an OwnPtr<Vector<u32>>. This is used as
a UTF-32 string builder. The substitution_code_point_view method uses
that Vector to provide a Utf32View of the specified length.
This patch fixes a bug where double-clicking on a word in a TextEditor
with syntax highlighting would also select an additional character after
the word. This also simplifies the logic for double- and
triple-clicking.
This patch brings all of LibVideo up to the east-const style in the
project. Additionally, it applies a few fixes from the reviews in #8170
that referred to older LibVideo code.
The TreeParser requires information about a lot of the decoder's
current state in order to parse syntax tree elements correctly, so
there has to be some communication between the Decoder and the
TreeParser. Previously, the Decoder would copy its state to the
TreeParser when it changed, however, this was a poor choice. Now,
the TreeParser simply has a reference to its owning Decoder, and
accesses its state directly.
This patch adds compressed header parsing to the VP9 decoder (section
6.4 of the spec). This is the final decoder step before we can start to
decode tiles.
This hack allows self-test mode run-tests-and-shutdown.sh to give
TestProcFs a stat(2)-able /proc/self/fd/0. For some reason, when
stdin is a SerialDevice, /proc/self/fd/0 will be a symlink to the device
as expected, but, calling realpath or stat on /proc/self/fd/0 will error
out. realpath will give the string from Device::absolute_path() which
would be something like "device:4,64 (SerialDevice)". When VFS is trying
to resolve_path so that we can stat the file, it would bail out on this
fake-y path.
Change the fake path (that doesn't show up when you ls a device, nor
when checking the devices tab in SystemMonitor) from the major/minor
device number and class_name() to /dev/device_name(). There's probably
a very hairy yak standing behind this issue that was only discovered due
to the ProcFS rework.
TestProcFs expects to be able to stat its stdout and stderr. The new
ProcFS implemetnation properly forwards the symlinks for
/proc/pid/fd/[1,2] to the temporary file that we had unlinked prior to
spawning the process. However, this makes it so that a normal stat on
the symlink to that file fails (as expected). Move the unlink to after
we've waited on the child, so that we know it won't be trying any funny
business with its stdout/stderr anymore.
This test program heavily pulls from the JavaScriptTestRunner/test-js,
but with a twist. Instead of loading JavaScript files into the current
process, constructing a JS environment for them, and executing test
suites/tests directly, run-tests posix_spawns each test file.
Test file stdout is written to a temp file, and only dumped to console
if the test fails or the verbose option is passed to the program. Unlike
test-js, times are always printed for every test executed for better
visibility in CI.
Split out the functionality to gather multiple tests from the filesystem
and run them in turn into Test::TestRunner, and leave the JavaScript
specific test harness logic in Test::JS::TestRunner and friends.
If someone runs the test with shell redirection going on, or in a way
that changes any of the standard file descriptors this assumption will
not hold. When running from a terminal normally, it is true however.
Instead, check that /proc/self/fd/[0,1,2] are symlinks, and can be
stat-d by verifying that both stat and lstat succeed, and give different
struct stat contents.
This introduces a new DOMTreeJSONModel, which provides the Model for the
InspectorWidget when the Browser is running using the
OutOfProcessWebView.
This Model is constructed with a JSON object received via IPC from the
WebContentServer.
Add `inspect_dom_tree` to WebContentServer and 'did_get_dom_tree' to
WebContentClient.
These two async methods form a request & response for requesting a JSON
representation of the Content's DOM tree.
This method builds a JSON object representing the full state of the
DOM tree.
The JSON that is built will be used for building the DOM Inspector
widget for the OutOfProcessWebView.
I regressed this in 648480f715.
We have to make sure JsonObjectSerializer::finish() is called before
writing out the blob. This is done automatically when the serializer
is destroyed, so just wrap them in scopes.
This fixes the build by hiding the problem from the compiler, but it's
a useful change in and of itself anyway.
A malloc/free per every mouse event is pretty annoying, especially when
we can actually avoid it.
It didn't make any sense to hardcode the modified time of all created
inodes with "mepoch", so we should query the procfs "backend" to get
the modified time value.
Since ProcFS is dynamically changed all the time, the modified time
equals to the querying time.
This could be changed if desired, by making the modified_time()
method virtual and overriding it in different procfs-backed objects :)
Instead of using one file for the entire "backend" of the ProcFS data
and metadata, we could split that file into two files that represent
2 logical chunks of the ProcFS exposed objects:
1. Global and inter-process information. This includes all fixed data in
the root folder of the ProcFS, networking information and the bus
folder.
2. Per-process information. This includes all dynamic data about a
process that resides in the /proc/PID/ folder.
This change makes it more easier to read the code and to change it,
hence we do it although there's no technical benefit from it now :)
The new ProcFS design consists of two main parts:
1. The representative ProcFS class, which is derived from the FS class.
The ProcFS and its inodes are much more lean - merely 3 classes to
represent the common type of inodes - regular files, symbolic links and
directories. They're backed by a ProcFSExposedComponent object, which
is responsible for the functional operation behind the scenes.
2. The backend of the ProcFS - the ProcFSComponentsRegistrar class
and all derived classes from the ProcFSExposedComponent class. These
together form the entire backend and handle all the functions you can
expect from the ProcFS.
The ProcFSExposedComponent derived classes split to 3 types in the
manner of lifetime in the kernel:
1. Persistent objects - this category includes all basic objects, like
the root folder, /proc/bus folder, main blob files in the root folders,
etc. These objects are persistent and cannot die ever.
2. Semi-persistent objects - this category includes all PID folders,
and subdirectories to the PID folders. It also includes exposed objects
like the unveil JSON'ed blob. These object are persistent as long as the
the responsible process they represent is still alive.
3. Dynamic objects - this category includes files in the subdirectories
of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially,
these objects are always created dynamically and when no longer in need
after being used, they're deallocated.
Nevertheless, the new allocated backend objects and inodes try to use
the same InodeIndex if possible - this might change only when a thread
dies and a new thread is born with a new thread stack, or when a file
descriptor is closed and a new one within the same file descriptor
number is opened. This is needed to actually be able to do something
useful with these objects.
The new design assures that many ProcFS instances can be used at once,
with one backend for usage for all instances.
