According to Dr. POSIX, we should allow to call mmap on inodes even on
ranges that currently don't map to any actual data. Trying to read or
write to those ranges should result in SIGBUS being sent to the thread
that did violating memory access.
To implement this restriction, we simply check if the result of
read_bytes on an Inode returns 0, which means we have nothing valid to
map to the program, hence it should receive a SIGBUS in that case.
Without this, the generated DOMExceptionConstructor does not refer to
the WebIDL::DOMException with its fully qualified name. This caused an
ambiguity error on my machine.
Given all of the other descriptions for each setting don't include a
period at the end, it won't hurt to have the TerminalSettings
description do the same for consistency.
This fixes an edge case, where the destination rect falls partly
outside the painter, so is clipped to a smaller size in
`get_region_bitmap()` (which needs to be accounted for with an extra
offset).
This now copies the area under the destination to a new bitmap, that
is then scaled to the size of the source. The element is then painted
into that bitmap, which is then scaled and painted back to
the destination. This is done as many effects such as shadows, border
radii, filters, etc require being able to read pixels from the painter.
This does work (and is not that noticeable in many cases), but it does
mean there may be a few scaling artifacts in the background
around transformed elements. Though that was already the case before
anyway for the elements (since it is just a bitmap scale).
What we really want is to (where possible) just scale the paintable
and its descendants, then paint things normally, which would give
much nicer results (but is much more tricky to achieve).
This also now makes it so only a bitmap of the size of the paintable is
copied/created, rather than the whole page.
This method returns the total area this element will paint to.
Currently, this just means accounting for box-shadows, though
there are likely more effects that need to be accounted for here.
This patch changes the *computed* representation of the following CSS
properties to use CSS::Size:
- width, min-width, max-width
- height, min-height, max-height
A few things had to change in order for things to keep working,
but I tried to keep the diff to a minimum.
The main trouble was that `min-width` and `max-width` can't actually be
`auto`, but they *can* be `none`. We previously treated `auto` as a
valid value (and it behaved mostly like `none`).
Until now, we've been using CSS::LengthPercentage, sometimes wrapped in
Optional, to represent CSS sizes.
This meant we could not support modern values like `min-content`,
`max-content`, `fit-content(<length>)`. We were also conflating `none`
and `auto` which made the `min-*` and `max-*` properties confusing.
The new CSS::Size class covers all possible size values as individual
substates. It'll be quite a bit of work to make all layout code aware of
the additional features, this patch merely makes the new type available.
We don't need to notify the web views that some deeply nested iframe
has started loading a new URL (and we don't want it showing up in the
browser location bar either!)
Two issues made this class unusable on other platforms:
- Hardcoded /res paths to icons
- It required a GUI::TreeView for palette access
This patch simply patches out those features on non-Serenity systemsf
for now.
When mousing over twitter, 17% of time was spent computing stacking
context transform origins. Since this never changes after the stacking
context is created, we can cache it and avoid all that work.
Let's stop putting generic types and AOs from the Web IDL spec into
the Bindings namespace and directory in LibWeb, and instead follow our
usual naming rules of 'directory = namespace = spec name'. The IDL
namespace is already used by LibIDL, so Web::WebIDL seems like a good
choice.
These are from the HTML spec and therefore belong in the HTML/ directory
in LibWeb. Bindings/ has become a bit of a dumping ground, so this is a
first step towards cleaning that up.
63c727a was meant to stop clipping absolutely positioned descendants,
but used `is_positioned()` rather than `is_absolutely_positioned()`,
which meant it disabled clipping in many more cases that it should
have.
This fixes an issue where, when looping over the components of a
composite glyph, we used to mutate the affine transformation of the
glyph itself when computing the transformations of its components.
(AffineTransform::multiply() is non-const).
In case of possible framebuffer mapping overflow, just fallback to the
safe mode-setting of the DisplayConnector, because in that state we know
for sure that we can map a usable framebuffer (otherwise it is a bug in
the Kernel, and not WindowServer).
This value will be used later on by WindowServer to reject resolutions
that will request a mapping that will overflow the hardware framebuffer
max length.
We simply don't need that field anymore, as it was used when one
FramebufferDevice could contain multiple framebuffers within it, each
for a connected screen head.
