Godot has a ScriptProcessorNode audio driver implementation for the
(deprecated) Web API.
As reported by some users, this fallback was not properly re-added
during the Godot 4 transition, and was left as "dead code".
While the API is deprecated, it is still supported by most browsers, and
some WebView may not implement AudioWorklet correctly (the new
recommended API).
This commit re-adds the ScriptProcessorNode implementation as a fallback
if the AudioWorklet driver fails to initialized (and can be forced if
desired via project settings as usual).
The spec says that Response.body can be null (in the event of requests that should have no body, like HEAD requests) and Firefox adheres to it which results in request failure for HEAD requests on Firefox for web exports.
This commit addresses that by treating a null body as an "empty" body (without using a polyfill) and avoids changing the request lifecycle as much as possible.
PR review changes:
- Use == instead of strict ===
- Do not use ?? null
- Comment formatting
Instead of calling loadDynamicLibraries ourselves, we add the
GDExtension libraries to preload to the "dynamicLibraries" module config
property.
This seems to fix some threading issue with some browsers during the
init phase.
Using 2.2.7.dev115+g0eb441d6.
Had to add `cancelled` to the ignore list, as it's a Wayland signal which
we're handling in our code, so we don't want codespell to fix that "typo".
Also includes the typo fix from #87927.
Co-authored-by: Divyanshu Shekhar <61140213+divshekhar@users.noreply.github.com>
It wrongly returned 20 on array buffers, which used to be the enumerator
value of Godot 3.x's type PoolByteArray, and now is the value of type Color,
while it should return 29 which is the enumerator value for PackedByteArray.
Body length cannot be reliably retrieved from the web.
Reading the "content-length" value will return a meaningless value when
the response is compressed, as reading will return uncompressed chunks
in any case, resulting in a mismatch between the detected body size and
the actual size returned by repeatedly calling read_response_body_chunk.
Additionally, while "content-length" is considered a safe CORS header,
"content-encoding" is not, so using the "content-encoding" to decide if
"content-length" is meaningful is not an option either.
We simply must accept the fact that browsers are awful when it comes to
networking APIs.
