Previously, the corner overlap algorithm implementation did not shrink
the border radii for zero width/height boxes, which resulted in
incorrect painting.
With this the implementation is updated to more closely follow the spec
steps, which naturally handles the zero width/height case. This makes
use of the `CSSPixelFraction` class for lossless comparison and
multiplication of the scaling factor for the radii.
Co-authored-by: Zaggy1024 <Zaggy1024@gmail.com>
This class will allow us to compare the ratio of two `CSSPixels` values
losslessly.
Not only that, but an operation like `a * (b / c)` should no longer
be lossy, since the operation can be carried out as `(a * b) / c`
implicitly instead.
Since we always pass the px value as an argument to resolved(), we can
pass it directly as CSSPixels instead of wrapping it in Length. This
approach allows us to avoid converting to a double, resulting in fewer
precision issues.
If we set m_waiting_for_messages to true for the intial message request,
we might never receive a response, and block the console from requesting
any more messages indefinitely. Instead, issue a non-blocking initial
request, which is how the Qt and Serenity chromes behaved before the
ConsoleClient abstraction.
This also changes ConsoleClient::clear() to use run_javascript() rather
than js_console_input(), as that is also how the chromes used to behave.
This adds menu items to open an interactive JavaScript console for a web
page. This more or less mimics the Qt implementation of the console.
Hooks are included to tie the lifetime of the console window with the
tab it belongs to; if the tab is closed, the console window is closed.
This creates WebView::ConsoleClient to handle functionality that will be
common to the JS consoles of all Ladybird chromes. This will let each
chrome focus on just the UI.
Note that this includes the `console.group` functionality that only the
Serenity chrome previously had. This was a FIXME in the Qt chrome, and
it is implemented such that all chromes will receive this functionality
for free.
The LadybirdWebView currently assumed it is viewed with a Tab instance.
This will not be true with the JavaScript console. This patch removes
this assumption by plumbing WebContent callbacks through a new protocol.
The Tab interface then implements this protocol.
For example, the JavaScript console will invoke window.scrollTo(0, INF)
to scroll to the bottom of the console after updating its contents. The
NSScrollView being scrolled here seems to behave oddly if we scroll
beyond its limit (e.g. mouse events stop working). Prevent this by
limiting scrolling to the NSScrollView's document rect.
We were relying on TabController setting the web view's initial viewport
in [TabController windowDidResize], which has been triggered when the
Tab is first created. However, it turns out that only happens due to the
toolbar being added to the Tab window, causing a resize event. When the
web view is embedded in a window without a toolbar, this resize event is
not triggered. Therefore, we must set the viewport ourselves when the
web view is added to a window.
All SQL callbacks here were already moving the to-be-executed callback
out of its storage before executing it, except for on_next_result().
This makes on_next_result() do the same move to ensure we do not later
attempt to move it while the callback is executing.
This is not we're supposed to do according to https://tc39.es/ecma262/#sec-runtime-semantics-propertydefinitionevaluation
Furthermore, this was observable by ToPrimitive looking up toString and
valueOf and potentially calling them if they exist. The big ticket
issue however is that for objects without toString and valueOf, such as
null-proto objects, this would unexpectedly throw.
When text paintables shift around in the tree due to line wrapping,
we may end up in a situation where some text node does not generate
a paintable (due to being all whitespace, for example), even though
in the previous layout pass, it *did* generate a paintable.
To prevent holding on to old paintables in such cases, we now do a
pass in LayoutState::commit() where we explicitly detach all old
paintables from the layout tree.
Currently, the only NSWindow type in the AppKit chrome is the Tab. Once
we have other window types (e.g. Inspector), commands which assume they
are used on a Tab will either crash or behave weirdly.
This changes the createNewTab: command to accept the tab from which the
new tab is created, rather than assuming that tab is the key window. So
if some JS on a page calls window.open() while a non-Tab window is key,
the new tab will be opened within the same tab group.
This also changes closeCurrentTab: to work on any key window. Regardless
of whether the key window is a Tab or some other window, pressing cmd+W
should just close that window.
This tokenizes a page's source to produce HTML with syntax highlighting.
The first implementation here is rather simple; we do not yet implement
code folding, line numbers, etc.
The goal is for this to be used as the View Source implementation for
all Ladybird chromes.
We currently track the [line, column] position of every HTMLToken, as
this is what is needed for LibGUI's syntax highlighting. Some non-LibGUI
purposes (e.g. highlighting HTML with HTML) require a byte offset. Track
both during tokenization.
This moves some stuff around to make LibGUI depend on LibSyntax instead
of the other way around, as not every application that wishes to do
syntax highlighting is necessarily a LibGUI (or even a GUI) application.
We need to start looking from the beginning of current row if adding
new implicit column track made enough space to accomodate spanning item
This fixes placement for spanning grid items when `grid-auto-flow` is
specified to `column`.
The `Loader` uses a `Vector<Sample>` to store any samples that the
actual audio decoder returned that the loader client did not request
yet. However, it did not take that buffer into account when those
clients asked for the number of samples loaded. The buffer is an
internal implementation detail, and should not be reflected on the
external API.
This allows LibWeb to keep better track of audio position without any
desync caused by the buffer. When using the Serenity `PlaybackStream`
implementation as the back end for an `HTMLAudioElement`, this allows
us to perfectly stop on the exact last sample of the audio file, so it
will not stop before the media element can see that it has finished
playback.
Note that `Loader::get_more_samples()` also calls `loaded_samples()` to
determine how many samples are remaining to load into the output
buffer. However, this change appears to be correct even there, given
that the samples copied from the internal sample buffer are included in
that count.
The behavior of the Serenity `PlaybackStream` implementation should
match the `AudioCodecPluginSerenity` class removed by this commit. Any
inconsistencies should be fixable without needing feature additions to
the underlying implementation.
The previous update time of 10 ms was set completely arbitrarily, but
puts an unnecessary load on the CPU. This reduces the rate, and it can
be adjusted in future depending on what web pages expect.
This implementation is very naive compared to the PulseAudio one.
Instead of using a callback implemented by the audio server connection
to push audio to the buffer, we have to poll on a timer to check when
we need to push the audio buffers. Implementing cross-process condition
variables into the audio queue class could allow us to avoid polling,
which may prove beneficial to CPU usage.
Audio timestamps will be accurate to the number of samples available,
but will count in increments of about 100ms and run ahead of the actual
audio being pushed to the device by the server.
Buffer underruns are completely ignored for now as well, since the
`AudioServer` has no way to know how many samples are actually written
in a single audio buffer.
The main change is the simplification of the expression
`(10^precision * fraction) / 2^precision` to `5^precision * fraction`.
Those expressions overflow or not depends on the value of `precision`
and `fraction`. For the maximum value of `fraction`, the following table
shows for which value of `precision` overflow will occur.
Old New
u32 08 10
u64 15 20
u128 30 39
As of now `u64` type is used to calculate the result of the expression.
Meaning that before, only FixedPoints with `precision` less than 15
could be accurately rendered (for every value of fraction) in decimal.
Now, this limit gets increased to 20.
This refactor also fixes, broken decimal render for explicitly specified
precision width in format string, and broken hexadecimal render.
By default, `1` is of the type `int` which is 32-bits wide at max.
Because of that, if `precision` of a `FixedPoint` is greater than 32,
the expression `1 << precision` will get clamped at 32-bits and the
result will always be zero. Casting `1` to the wider underlying type
will make the expression not overflow.
Because of the off-by-one error, the second bit of the fraction was
getting ignored in differentiating between fractions equal to 0.5 or
greater than 0.5. This resulted in numbers like 2.75 being considered
as having fraction equal to 0.5 and getting rounded incorrectly (to 2).
