This commit changes the variables used to represent the size and
progress of downloads from u32 to u64. This allows `pro` and
`Browser` to report the total size and progress of a download
correctly for downloads larger than 4GiB.
In particular:
- Don't include none submitter buttons.
- Use type_state() instead type() to avoid direct string comparisons
- Support the hidden _charset_ input
- Get form associated element's value directly instead of via the value
attribute
- Split line break normalization into a separate function so that it
can also be used by form submission.
With multi-line text cells, we don't reliably know the height would stay
the same as the one set by the independent format context run. In such
situations, we can end up with a table box which is sized inconsistently
with the grid boxes of the table due to differences in line breaks.
Works for fills and strokes (using colors, gradients, or patterns),
along with images.
fill_rect() has been updated to use fill_path(), which allows it to
easily transform the rect, and already supports opacity.
Co-authored-by: MacDue <macdue@dueutil.tech>
This is not to the specification, but as the FIXME comment for the
function states, we need it to be able to properly interface with the
FileAPI spcification, which seems to have not been updated to the non
promise based API.
This algorithm is used by ReadableStreamDefaultReader to read all bytes
from a given stream. Currently the algorithm used is somewhat naive as
it is recursive, but given the initial use of this reader, it should not
be a problem.
I found myself needing to call this method when attempting to implement
Blob::text and Blob::array_buffer. Turns out that the only caller
outside of the Detail namespace already had a FIXME to make this a
public API - so let's do that.
In compute_table_box_width_inside_table_wrapper, we should only consider
available_width when it's valid. Values which come from {min,
max}-content constraints aren't meaningful and shouldn't be considered
for the cap.
The translation to the bounding box location is handled by the gradient
transform, also doing it here breaks things.
This fixes the MDN <radialGradient> example.
Absolutely positioned elements should have their percentage sizes
resolved against the padding box of the containing block, not the
content box.
From CSS-POSITION-3 <https://www.w3.org/TR/css-position-3/#def-cb>
"..the containing block is formed by the padding edge of the ancestor.."
Now that we support audio, we can start correctly reporting we support
certain audio mime types!
Required by certain sites like Gartic Phone, which fails to load audio
because we didn't return a non-empty string for `audio/mpeg`:
```
"https://garticphone.com/sounds/turnundefined", Error: Load failed: 404
```
```js
(new Audio).canPlayType("audio/mpeg") && (this._extension = ".mp3"),
```
The transform can change between path building operations (and before
the path is filled or stroked). This fixes the sun ray backgroun on
the https://www.kevs3d.co.uk/dev/html5logo/ canvas demo.
The data we want to send out of the WebContent process is identical for
audio and video elements. Rather than just duplicating all of this for
audio, generalize the names used for this IPC for all media elements.
This also encapsulates that data into a struct. This makes adding new
fields to be sent much easier (such as an upcoming field for muting the
element).
The audio element behaves a bit differently than the video element in
that the audio element drives itself on a timer (as opposed to LibVideo
notifying the video element when a frame is available). So if an audio
element is paused while seeking, we wouldn't receive an updated playback
position until the element is unpaused.
This fixes an issue where you would have to click the play button twice
to re-start an audio track after it reached the end.
Previously, using an identifier color like `currentColor` would fail to
parse, since we look at ident tokens (and reject unrecognised ones)
before trying to parse colors.
When resolving a percentage min-width or min-height size against a
containing block currently under a min-content constraint, we should act
as if the containing block has zero size in that axis.
The idea here is to let us decide ahead of time what components to paint
depending on the size available. We currently paint each component left-
to-right, until we run out of room. This implicitly gives priority to
the left-most components.
We will soon paint volume controls on the right-side of the timeline.
Subjectively, they should have a higher priority than, say, the timeline
scrubbing bar (i.e. it's more important to be able to mute audio than to
seek). By computing these components before painting, we can more easily
allocate sections to the components in priority order, until the area
remaining has been depleted.
It can take some time to download / decode a media resource. During this
time, its duration is set to NaN. The media control box would then have
some odd rendering glitches as it tried to treat NaN as an actual time.
Once we do have a duration, we also must ensure the media control box is
updated.
