While DeprecatedString and StringView use ASCII case-insensitivity when
matching, String uses the Unicode rules, so in order to match the spec,
we need to *not* use `String::equals_ignoring_case()`.
This function needs to be used everywhere that the spec refers to
an "ASCII case-insensitive match".
These are only used for debugging, so I've decided that logging the
ErrorOr<String> itself is fine instead of trying to handle that error
more gracefully in those cases. If you're getting OOM trying to debug
log things, you have bigger problems.
The checkbox provided by ClassicStylePainter is not scaling-aware and
generally unflexible, instead use the UA default stylesheet with a
handful of properties, the same way we already style buttons and text
inputs.
Thanks to Xexxa for the nice checkmark image!
Co-Authored-By: Xexxa <93391300+Xexxa@users.noreply.github.com>
This is a normative change in the Fetch spec.
See: e4d3480
This also implements the changes to the 'sort and combine' algorithm,
which now treats "set-cookie" headers differently, and is exposed to JS
via the Headers' iterator.
Passes all 21 WPT tests :^)
http://wpt.live/fetch/api/headers/header-setcookie.any.html
We can't keep a span (ReadonlyBytes) to a move()'d ByteBuffer
in the header_names_seen HashTable - copy the original name span instead
which works the same thanks to CaseInsensitiveBytesTraits.
This would sporadically fail the contains() check due to garbage data,
later leading to a VERIFY() crash in the OrderedHashTable append loop.
The main things missing is the CORS preflight cache and making
extract_header_list_values properly parse, validate and return split
values for the Access-Control headers.
Previously, parsing failures and the header not existing made
extract_header_list_values return an empty Optional, making it
impossible to differentiate between the two.
Required for implementing CORS-preflight, where parsing failures for
the headers makes it fail, but not having them doesn't make it fail in
all cases.
Using LoadRequest::create_for_url_on_page will unconditionally add
cookies as long as there's a page available. However, it is up to
http_network_or_cache_fetch to determine if cookies should be added to
the request.
This was noticed when implementing CORS-preflight requests, where we
sent cookies in OPTIONS requests.
If a box has clearance and margin bottom of preceding box is greater
than static y of the box then it should also affect y offset in current
block container so subsequent boxes will get correct y position too.
For example, consider cases where we want to propagate errors only in
specific instances:
auto result = read_data(); // something like ErrorOr<ByteBuffer>
if (result.is_error() && result.error().code() != EINTR)
continue;
auto bytes = TRY(result);
The TRY invocation will currently copy the byte buffer when the
expression (in this case, just a local variable) is stored into
_temporary_result.
This patch binds the expression to a reference to prevent such copies.
In less trival invocations (such as TRY(some_function()), this will
incur only temporary lifetime extensions, i.e. no functional change.
