When decoding a CMYK image and asked for a normal `frame()`, the decoder
would convert the CMYK bitmap into an RGB bitmap. Calling `cmyk_frame()`
after that point will provoke a null-dereference.
The only downside is we are limited to 4 recent projects now. LibGUI
currently relies on the number of recent files being constexpr, so that
will take some more work to make it variable.
We previously assumed that `set_most_recently_open_file()` would only be
called after `Menu::add_recent_files_list()` had been called, and would
crash if we hadn't called it yet. This stops the crash. We're fine to
do this, because we always call `update_recent_file_actions()` in
`register_recent_file_actions()` so it's guaranteed to be up to date
when we do need it.
A couple of tweaks here to make it work better:
- Call `set_cursor_and_focus_line()` to make the Editor scroll to the
symbol's location.
- Remove focus from the Locator's text box so your cursor jumps to the
Editor instead of staying in the Locator.
This being a Popup window meant it behaved in a couple of janky ways:
- It would steal the focus each time it was shown, so after every key
press in the TextBox.
- It would disappear when you focused that TextBox again.
Using the Autocomplete window type fixes both of these. While the
Locator is not technically an autocomplete, it shares the general "type
and get suggestions based on the input, which you can select" behavior,
so this is close enough.
Also change a Vector<Handle> to a Vector<NonnullGCPtr> while we're
here, since there's no need to use handles for members of a cell.
Fixes an ASAN error on the HTML/Window-postMessage.html test.
We should be using WebIDL Promise in these methods, per the spec
references in other specifications. That is, the HTML spec always links
to WebIDL when it talks about `Promise<T>`. The Crypto seems to be
missing those cross-references.
While we're here, actually resolve the digest promise in parallel.
I just copy-pasted microseconds_since_boot and
set_interrupt_interval_usec from aarch64.
However, on RISC-V, they are not in microseconds.
The TimerRegisters struct is also unused.
current_time and set_compare can also be private and static.
IRQHandler is not the correct class to inherit from, as the timer
is not connected to an IRQController.
Each hart has one of these Timers directly connected to it.
I originally added this header because I misunderstood how
IRQControllers are supposed to be used.
I thought that I would need a IRQController class for the hart-local
interrupt controller, but apparently, this class is supposed to be used
for non-local interrupt controllers like the IOAPIC or RISC-V PLIC.
x86 LAPICs don't use this class either.
Previously, our code for the fixup of table rows assumed that missing
cells in a table row must be sequential. This may not be true if the
table contains cells have a rowspan greater than one.
We now split up symbols into zero-sized symbols that label single
instructions (no need to separate them by newlines; they are used for
jump labels and relocation targets within a larger block of code) and
ranged symbols that label functions. Empty symbols are discarded since
at least RISC-V ELF files contain quite a few of those. Zero-sized
symbols and ranged symbols are handled almost the same, but this way we
can make sure that zero-sized symbols don't interfere with ranged
symbol's newline separation logic. For zero-sized symbols, the "symbol
contains address" logic is updated so they actually contain the one
address they're pointing at, fixing the bug with many "dangling"
zero-sized symbols after a function that contained them. Zero-sized
labels are also no longer printed as a start-end range, since that is
unnecessary visual noise.
We previously were considering Float and Doubles as non-supported types.
But this was done in a sneaky way, by letting them hit the default case
in the `read_type` method. So, when I ported this function to the
generator we started to make this types flow into the system without a
proper support there. Since 3124c161, we would have crashes on images
containing tags with a floating point value.
A lot of images format use Exif to store there metadata. As Exif is
based on the TIFF structure, the TIFF decoder can, without modification
be able to decode the metadata. We only need a new API to explicitly
mention that we only need the metadata.
Support for JPEGs embedded in TIFF images was introduced with TIFF 6.0.
However, this implementation had major issues. It was so problematic
that they decided to reimplement it from scratch in 1995, three years
later. The two incarnations are obviously incompatible.
For more details see:
https://www.awaresystems.be/imaging/tiff/specification/TIFFTechNote2.txt
