Required by code that brand checks native constructors.
For example, Wistia brand checks XMLHttpRequest by doing:
```
XMLHttpRequest.prototype.constructor.toString()
```
It then checks if it matches either one of:
```
function XMLHttpRequest() { [native code] }
```
```
[object XMLHttpRequestConstructor]
```
If neither matches, it disables HLS playback and prints:
"The XMLHttpRequest constructor has been tampered with. Because this
affects CORS/Range XHR requests, HLS playback has been disabled.
To enable HLS playback and other important features, please remove code
that changes the definition of window.XMLHttpRequest."
We hit this path due to not giving generated constructors a name, as
we would provide `function () { [native code] }`.
Currently, the WebAssemblyObject implements a visitor to keep its static
objects alive. This custom attribute will be used to hook the generated
namespace object's visitor to one that we define in non-generated code.
This is used by WebAssembly IDL files. For now, we mostly use this for
error messages and cache keys (to ensure compatibility with existing
code as WebAssembly is ported to IDL).
For example, consider the attribute:
interface Element {
[PutForwards=value] readonly attribute DOMTokenList classList;
}
When `classList` is set, we should instead set the attribute `value` on
the `classList` attribute of the Element interface.
Don't try to reserve capacity for a variadic arguments list unless we
actually have enough arguments to fill it with anything. Otherwise we
may overflow to an extremely large size if, e.g., the argument count
is 0 and the start of the variadic arguments is index 1.
Similar to POSIX read, the basic read and write functions of AK::Stream
do not have a lower limit of how much data they read or write (apart
from "none at all").
Rename the functions to "read some [data]" and "write some [data]" (with
"data" being omitted, since everything here is reading and writing data)
to make them sufficiently distinct from the functions that ensure to
use the entire buffer (which should be the go-to function for most
usages).
No functional changes, just a lot of new FIXMEs.
When an IDL file has #imports and the IDL interface exposes an iterator,
the bindings generator would generate #include statements missing the
class name of the iterator in the form 'LibWeb/{namespace}/Iterator'.
This change only generates the iterator #include statement for the top
interface that is the iterator.
These are treated differently as the interface members are placed on the
object itself, not its prototype.
As the object itself still needs to be hand-written code, and we can no
longer fully hide the gnarly generated code in the prototype object,
these now generate a 'mixin' class that is added to the actual object
through inheritance.
https://webidl.spec.whatwg.org/#Global
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
This commit moves the implementation of getopt into AK, and converts its
API to understand and use StringView instead of char*.
Everything else is caught in the crossfire of making
Option::accept_value() take a StringView instead of a char const*.
With this, we must now pass a Span<StringView> to ArgsParser::parse(),
applications using LibMain are unaffected, but anything not using that
or taking its own argc/argv has to construct a Vector<StringView> for
this method.
This adds the condition member.type->is_string() to the if statement, so
that we now conditionally check the dictionary member is a new string
and associated with an optional constructor parameter.
When a constructor has an optional dictionary as argument, and those
members are of type new string, make sure that we release_value()
setting the dictionary members.
This makes use of the new [UseNewAKString] extended attribute. Using
Vector storage will make it easier to make this interface into an IDL
iterable. It seems the reason it didn't use Vector originally was due
to awkward DeprecatedString -> String conversions.
Adding the [UseNewAKString] extended attribute to an interface will
cause all IDL string types to use String instead of DeprecatedString.
This is done on an per interface level instead of per type/parameter
because:
- It's much simpler to implement, as the generators can already access
the interface's extended attributes. Doing it per type/parameter
would mean parsing and piping extended attributes for each type that
doesn't already take extended attributes, such as unions.
- Allows more incremental adoption of AK::String. For example, adding
[UseNewAKString] to BodyInit would require refactoring Request,
Response and XMLHttpRequest to AK::String in one swoop. Doing it on
the interface allows you to convert just XHR and its dependencies at
once, for example.
- Simple string return types (i.e. not parameterised or not in a union)
already accept any of the string types JS::PrimitiveString::create
accepts. For example, you can add [UseNewAKString] to DOMStringMap to
convert Element attributes to AK::String and still return AK::String
from get_attribute, without adding [UseNewAKString] to Element.
- Adding [UseNewAKString] to one function typically means adding it to
a bunch of other functions, if not the rest of them. For example,
adding [UseNewAKString] to the parameters FormData.append would
either mean converting AK::String to AK::DeprecatedString or storing
the AK::String as-is, making the other functions of FormData have to
convert back from AK::String or also support AK::String.
This includes an Error::create overload to create an Error from a UTF-8
StringView. If creating a String from that view fails, the factory will
return an OOM InternalError instead. VM::throw_completion can also make
use of this overload via its perfect forwarding.
