Semaphores with values greater than one didn't work because whoever
called sem_wait() first held the semaphore's mutex until a matching
sem_post() call.
Other callers then wouldn't be able to acquire the semaphore even
if the semaphore's value was still greater than zero at that point.
Fixes#6325
The JavaScript on the HTML Spec site that caused the crash is:
window.location.hash.substr(1)
Of course, window.location.hash can be the empty string. The spec allows
for calling substr(1) on an empty string, but our partial implementation
wasn't handling it properly.
As defined by the specification (and used by the website i am testing):
interface mixin CanvasDrawPath {
undefined fill(optional CanvasFillRule fillRule = "nonzero");
}
Since we first check the winding number and only then update it, fills
for "Rectangle-like" (made up of 2 parallel segments) paths would draw
nothing when filled by NonZero winding rules. (Fix by alimpfard)
According to @Baitinq the original port crashed with audio enabled.
I suspect that this was because the SDL2 headers didn't match between
the host and target system. Now that we properly use target's headers
this is no longer an issue so I enabled audio:
https://www.youtube.com/watch?v=ZTFvrcpZjY8
I was trying to port openttd which I ultimately gave up on because
too much of the C++ standard library's functionality is missing at this
point. The libicu library was a dependency for that.
In its current state the libicu port is not thread-safe because of
missing functionality in the C++ standard library (mainly std::mutex,
std::condition_variable, etc.).
This is useful for ports which depend on running tools on the host system.
In this case we can build the port twice - once for the host and once for
the target system.
To implement the HttpOnly attribute, the CookieJar needs to know where a
request originated from. Namely, it needs to distinguish between HTTP /
non-HTTP (i.e. JavaScript) requests. When the HttpOnly attribute is set,
requests from JavaScript are to be blocked.
This moves the cookie parsing steps out of CookieJar into their own file
inside LibWeb. It makes sense for the cookie structures to be in LibWeb
for a couple reasons:
1. There are some steps in the spec that will need to partially happen
from LibWeb, such as the HttpOnly attribute.
2. Parsing the cookie string will be safer if it happens in the OOP tab
rather than the main Browser process. Then if the parser blows up due
to a malformed cookie, only that tab will be affected.
3. Cookies in general are a Web concept not specific to a browser.
Since our tests usually take at least 10 minutes theres no point in
checking every 10 seconds, and github was starting to complain about
the very high API usage.
