Any left-over comments in the pending_comments vector are now inserted
as sub object children, as these are serialized last and will therefore
show up in their expected location.
The spec notes that this AO is unused by ECMA-262, but is provided for
ECMAScript hosts. Move the definition to a common location to allow
test-js to also use it.
This is used to skip downloading fonts in formats that we don't support.
Currently we only support TTF as far as I am aware.
The parts of a `src` are in a fixed order, unusually, which makes the
parsing more nesty instead of loopy.
Like, An+B, this is an old construct that does not fit well with modern
CSS syntax, so things get a bit hairy! We have to determine which
tokens match the grammar for `<urange>`, then turn those back into a
string, and then parse the string differently from normal. Thankfully
the spec describes in detail how to do that. :^)
This is not 100% correct, since we are not using the original source
text (referred to in the spec as the "representation") of the tokens,
but just converting them to strings in a manual, ad-hoc way.
Re-engineering the Tokenizer to keep that original text was too much of
a tangent for today. In any case, we do parse `U+4???`, `U+0-100`,
`U+1234`, and similar, so good enough for now!
"Component value" is the term used in the spec, and it doesn't conflict
with any other types, so let's use the shorter name. :^)
Also, this doesn't need to be friends with the Parser any more.
Previously, we only remapped the destination rect through the context's
affine transform, but didn't actually paint through it.
This patch fixes that by implementing a very inefficient algorithm for
rasterizing a transformed bitmap. When the context has a plain identity
transform, we bypass this algorithm in favor of calling Gfx::Painter
directly as we did before.
This makes the player character in "Biolab Disaster" able to turn left!
Unlike map(Rect) which returns a Rect, mapping a Rect to a Quad allows
us to represent the actual result of mapping all four corners of the
Rect through the matrix.
This mainly does two things,
1. Removes spaces after commas
2. Elides "0x" and leading zeros in most contexts
Remaining differences are:
1. objdump always has memory size annotations
We lack these and probably have some annotations wrong
2. Boolean check names
We use jump-zero, while objdump uses jump-equal for example
3. We sometimes add "00 00" symbols, which objdump elides
4. We always demangle (This is a good thing)
5. We always resolve relocations (This is a good thing)
6. We seem to detect some symbols differently/incorrectly
This prints 7 instruction bytes per line, which is enough for most
x86-64 instructions (rex+opcode+mod/rm+imm32) and is also what
objdump uses.
Co-authored-by: Simon Wanner <skyrising@pvpctutorials.de>
This adds a value inspector window to the Hex Editor. This window shows
the data at the current cursor position (or selection start if a range
is selected) interpreted as a variety of data types.
Currently supported values include 8, 16, 32, and 64 bit signed and
unsigned values as well as float and double.
The inspector can operate in both little endian and big endian modes.
This is switched between by options in the View menu.
Instead of downloading nearly 20 files individually, we can download a
single .zip file similar to how we download a single CLDR .zip. This is
to reduce the number of connections/downloads to/from unicode.org.
Having bogus values here when we just initialize the thread state with a
process can lead to all sorts of bad things down the line, like infinite
draws.
In the process model we check the thread with tid=pid to figure out the
main thread of a process. This is used to construct the process view
tree with non-main threads listed as children of the process row.
However, there are sometimes circumstances where there is no main
thread, even though the process should have been removed from the
internal list by then. As a safe fallback, let's default to an invalid
model index if we can't figure out what the main thread of a process is.
BrowsingContext shouldn't be scrolling itself, instead it has to update
the layout (to ensure that we have current document metrics, and then
ask the PageClient nicely to scroll it.
This fixes an issue where BrowsingContext sometimes believed itself to
be scrolled, but OOPWV had a different idea.
This was a mixin class that allowed sharing a set of hooks between
InProcessWebView and OutOfProcessWebView. Now that there is only OOPWV,
we don't need the mixin.
