We were mistakenly treating inline replaced elements as if they are the
start of a regular display:inline element. This meant that we collected
the horizontal start and end metrics from the box model, and then added
those to the inline-level item produced by InlineLevelIterator.
This effectively meant that <img>, <svg> and other replaced elements got
double-sized values for margin/border/padding on the left and right
sides. (Which manifested as a mysterious margin around the element.)
Previously, we were running the "load fonts if needed" machine at the
start of every style computation. That was a lot of unnecessary work,
especially on sites with lots of style rules, since we had to traverse
every style sheet to see if any @font-face rules needed loading.
With this patch, we now load fonts once per sheet, right after adding
it to a document's style sheet list.
Give the Paintable class some basic helpers for traversing the paint
tree. Note that they actually piggy-back on the layout tree for links
between nodes.
A change was made prior to percent encode plus signs in order to fix an
issue with the Google cookie consent page.
Unforunately, this was treating a symptom of a problem and not the root
cause and is incorrect behavior.
When cloning the PaintContext we should be using the painter backed by
the bitmap created for this stacking context layer.
Fixes: 54c3053bc3 ("LibWeb: Preserve paint state when painting...")
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.
