This caused us to report one purged page per occurrence of the shared
zero page in a purgeable memory region, despite it being a no-op.
Thanks to Sergey for spotting the bad assertion removal that led to
this being found!
This patch adds PageFaultResponse::OutOfMemory which informs the fault
handler that we were unable to allocate a necessary physical page and
cannot continue.
In response to this, the kernel will crash the current process. Because
we are OOM, we can't symbolicate the crash like we normally would
(since the ELF symbolication code needs to allocate), so we also
communicate to Process::crash() that we're out of memory.
Now we can survive "allocate 300 MB" (only the allocate process dies.)
This is definitely not perfect and can easily end up killing a random
innocent other process who happened to allocate one page at the wrong
time, but it's a *lot* better than panicking on OOM. :^)
This function has a lot of callers that don't bother checking if it
returns successfully or not. We'll need to handle failure in a bunch
of places and then we can remove this assertion.
When we switched the Bitmap code to operating 32 bits at a time,
we neglected to look in the trailing remainder bits after the last
full 32-bit word.
This patch fixes that and adds a couple of tests for Bitmap that I
hacked up while tracking down this bug.
I found this bug when noticing that the kernel would OOM while there
were still some pages left in the physical page allocator.
This allows easy creation of a new string from an existing StringView.
Can be used e.g. for output with printf(..., view.to_string().characters())
instead of writing printf(..., String{view}.characters()).
"[Function.length is] the number of formal parameters. This number
excludes the rest parameter and only includes parameters before
the first one with a default value." - MDN
This implements only one of the two forms of this function,
ctx.fill(winding_rule).
Also tweaks the quadratic curve demo to have a nice looking filled
shape.
There are some imperfections with intersecting edges (because the main
algorithm used is scanline, and that is not geared towards drawing
complex shapes), however, it behaves mostly fine for normal use :^)
To make processing tagged template literals easier, template literals
will now add one empty StringLiteral before and after each template
expression *if* there's no other string - e.g.:
`${foo}` -> "", foo, ""
`test${foo}${bar}test` -> "test", foo, "", bar, "test"
This also matches the behaviour of many other parsers.
A regression was introduced in dc9b4da where the parser would
incorrectly parse the assignment of arrow functions to (non-declaration)
variables. For example, consider:
a = () => {}
Because the parser was aware of default parameters, in
try_parse_arrow_function, the equals sign would be interpreted as a
default argument, leading to incorrect parsing of the overall
expression. Also resulted in some funny behavior
(a = () => {} => {} worked just fine!).
The simple fix is to only look for default parameters if the arrow
function is required to have parenthesis.
If a button is checkable, its "checked" state is inversed in
Button::click. It's not needed for taskbar buttons - their checked
state is updated in TaskbarWindow::wm_event, based on the
current state of their window.
Fixes: #1878.
We now allow you to download files by right-clicking a link and then
choosing "Download".
All files are currently saved to the standard downloads location that
we get from Core::StandardPaths::downloads_directory().
In the future, we'll probably want to come up with a more restrictive
way of doing the "write to disk" portion of this.
We should also improve the ProtocolServer to allow streaming of data
instead of writing everything in one big go.
At the moment, I'm just pretty happy with this GUI. :^)
This display type is implemented using a LayoutBlock that is_inline().
Basically it behaves like a block internally, and its children are laid
out in the normal block layout fashion. Externally however, it behaves
like an atomic inline-level box.
Layout of inline-block boxes happens in three stages:
1. The outer dimensions of the block are computed during the recursive
normal layout pass. We skip positioning, but lay out children.
2. Later on, during line layout in the *containing block*, the inline
block now contributes a linebox fragment. When linebox fragments are
positioned, we learn the final position of the inline block. That's
when we set the inline block's position.
3. We re-layout the inline block's children once again. This is done to
make sure they end up in the right position. The layout tree doesn't
use relative offsets, so after we position the inline block in (2),
its children will not have its positions updated. Relayout moves
all children of inline blocks to the right place.
This is a rather naive approach but it does get the basic behavior into
place so we can iterate on it. :^)
It's still only a dummy as LibWeb doesn't have focused elements yet, but
at least now we don't treat "selector:focus" as just "selector".
This fixes an issue on google.com which was mostly grey - coming from
some menu item focus styles :^)
The spec defines the only valid methods to be get, post, and dialog.
Post and dialog are currently unhandled and do nothing, any other value
(or no value specified) is defined by the spec to use the get method.
