Concerned functions are:
- try_request_file_read_only_approved_deprecated
- try_request_file_deprecated
- try_open_file_deprecated
- try_save_file_deprecated
It also allows some simplifications in the implementation of the client.
Having an alias function that only wraps another one is silly, and
keeping the more obvious name should flush out more uses of deprecated
strings.
No behavior change.
The new result returned just a file stream, which wasn't sufficient
enough for most applications because it didn't provide a filename.
This patch will make a new File object that has both a file stream and
a filename.
Rip that bandaid off!
This does the following, in one big, awkward jump:
- Replace all uses of `set_main_widget<Foo>()` with the `try` version.
- Remove `set_main_widget<Foo>()`.
- Rename the `try` version to just be `set_main_widget` because it's now
the only one.
The majority of places that call `set_main_widget<Foo>()` are inside
constructors, so this unfortunately gives us a big batch of new
`release_value_but_fixme_should_propagate_errors()` calls.
About half of the usages were not using `force` anyways, and the other
half presumably just got confused about what "force" really means in
this context (which is "ignore nonexistent files").
The only 'legitimate' user, which is `rm`, instead now handles this
completely internally instead.
This patch allows returning an `Error` from the `on_complete` callback
in `BackgroundAction`.
It also adds a custom callback to manage errors returned during its
execution.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Even though this almost certainly wouldn't run properly even if we had
a working kernel for AARCH64 this at least lets us build all the
userland binaries.
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 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.
StringView was used where possible. Some utilities still use libc
functions which expect null-terminated strings, so String objects were
used there instead.
The main event loop functionality was used in just two places where the
alternative is a bit simpler. Remove it in favor of referencing the
event loop directly, or just invoking `EventLoop::current()`.
Note that we don't need locking in the constructor since we're now only
modifying a thread-local `Vector`. We also don't need locking in the
old call sites to `::with_main_locked()` since we already lock the
event loop in the subsequent `::post_event()` invocation.
Previously we captured them by reference, but when the deferred code
finally runs from an event loop, the references may be stale.
In that case, value and max of the progressbar are set with random
numbers.
If we were especially unlucky, the `frame_count` turned into a negative
int, and would crash at `VERIFY(min <= max)`.
The idea of locking the process veil in CrashReproter is well
intentioned, but ultimately frought with issues.
The fundamental premise is a bit flawed, as we are using the crashing
program as input to dynamically add new paths to the process veil.
This means that an attacker can potentially produce a custom or
malformed binary to trick CrashReporter into allowing an arbitrary
path to be read.
We can't fiddle with GUI widgets off the main thread, so let's use
Core::EventLoop::deferred_invoke() to dispatch the work.
The progress bar doesn't visibly update yet, but at least we're not
crashing anymore.
Previously when opening a crash report for HackStudio, the
`unveil("/bin/HackStudio", "rx")` call was failing because of the
earlier `unveil(executable_path.characters(), "r")` call requesting only
"r" permissions for it. This patch handles this specific case, so you
can crash HackStudio to your heart's content. :^)
Also, we were unveiling the executable path twice, once manually and
once implicitly as part of the coredump's libraries, so we now check for
the latter and avoid it.
Thanks to Daniel for noticing what was right in front of me and I didn't
see!
Co-authored-by: Daniel Bertalan <dani@danielbertalan.dev>
Previously we would create a temporary progress window to show a
progressbar while the coredump is processed. Since we're only waiting
on backtraces and CPU register states, we can move the progressbar
into the main window and show everything else immediately while the
slow parts are generated in a BackgroundAction.
Previously, when the --unlink flag was passed to CrashReporter, it
unlinked the coredump file immediately after reading it.
This change makes it so the coredump file is deleted when CrashReporter
exits.
Some coredumps take a long time to symbolicate, so let's show a simple
window with a progress bar while they are loading.
I'm not super happy with the factoring of this feature, but it's an
absolutely kickass feature that makes crashing feel 100% more responsive
than before, since you now get GUI feedback almost immediately after a
crash occurs. :^)
