This commit:
- Prevents path traversal via the about: scheme
- Prevents loading about:inspector
- Requires about: URIs to be opaque paths
- Prevents crashes with invalid percent encoded paths
This has been a longstanding ergonomic issue with our IPC compiler. Non-
trivial types were previously passed by const&. So if we wanted to avoid
expensive copies, we would have to const_cast and move the data.
We now pass ownership of all transferred data to the client subclasses.
This allows us to remove const_cast from these methods, and allows us to
avoid some trivial expensive copies that we didn't bother to const_cast.
For example, consider the following IPC message:
do_something(u64 page_id, String string, Vector<Data> data) =|
We would previously generate the following C++ method to encode/transfer
this message:
void do_something(u64 page_id, String string, Vector<Data> data);
This required the caller to either have to copy the non-trivial types or
`move` them in. In some places, this meant we had to construct temporary
vectors just to send an IPC.
This isn't necessary because we weren't holding onto these parameters
anyways. We would construct an IPC::Message subclass with them (which
does require owning types), but then immediate encode the message to
an IPC::MessageBuffer and send it.
We now generate code such that we don't need to construct a Message. We
can simply encode the parameters directly without needing ownership.
This allows us to take view-types to IPC parameters.
So the above example now becomes:
void do_something(u64, StringView, ReadonlySpan<Data>);
This will be needed in an upcoming commit so that this method may call
itself recursively to generate overloads. Doing this extraction ahead of
time will simply make that diff easier to grok.
This isn't particularly important, but when staring at generated IPC
files, it's nice not to have an extra newline after every line of code
throughout the files.
This commit adds support for using the standard library implementation
of <stacktrace> if libbacktrace is not found. This can also be
explicitly enabled through ENABLE_STD_STACKTRACE for platforms that have
libbacktrace available.
Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
The DOMParsing spec is in the process of being merged into the HTML one,
gradually. The linked spec change moves XMLSerializer, but many of the
algorithms are still in the DOMParsing spec so I've left the links to
those alone.
I've done my best to update the GN build but since I'm not actually
using it, I might have done that wrong.
Corresponds to 2edb8cc7ee
Having multiple kinds of node that hold numeric values made things more
complicated than they needed to be, and we were already converting
ConstantCalculationNodes to NumericCalculationNodes in the first
simplification pass that happens at parse-time, so they didn't exist
after that.
As noted, the spec allows for other contexts to introduce their own
numeric keywords, which might be resolved later than parse-time. We'll
need a different mechanism to support those, but
ConstantCalculationNode could not have done so anyway.
Before this change, we only parsed fit-content as a standalone keyword,
but CSS-SIZING-3 added it as a function as well. I don't know of
anything else in CSS that is overloaded like this, so it ends up looking
a little awkward in the implementation.
Note that a lot of code had already been prepped for fit-content values
to have an argument, we just weren't parsing it.
To aid with debugging web page issues in Ladybird without needing to
implement a fully fledged inspector, we can implement the Firefox
DevTools protocol and use their DevTools. The protocol is described
here:
https://firefox-source-docs.mozilla.org/devtools/backend/protocol.html
This commit contains just enough to connect to Ladybird from a DevTools
client.
This makes it so that the IDL generator no longer assumed that
dictionary members with a default value are optional, since they
will always, at least, have the default value.
All fields are always initialized, so we don't need to initialize them
by default. This lets us send types over IPC that can't be
default-constructed, such as a Variant without Empty.
At some point, we stopped ever constructing invalid messages. This makes
that clearer, and will allow us to stop requiring that IPC arguments be
default-constructible.
It might be a good idea to do this on other platforms as well, but at
least on Windows, the command line for GenerateWindowOrWorkerInterfaces
becomes too large.
This is not a very pleasant fix, but matches a similar const_cast that
we do to return JS objects returned in a union. Ideally we would
'simply' remove the const from the value being visited in the variant,
but that opens up a whole can of worms where we are currently relying on
temporary lifetime extension so that interfaces can return a Variant of
GC::Ref's to JS::Objects.
We were previously assuming that dictionary members were always
required when being returned.
This is a bit of a weird case, because unlike _input_ dictionaries
which the spec marks as required, 'result' dictionaries do not seem to
be marked in spec IDL as required. This is still fine from the POV that
the spec is written as it states that we should only be putting the
values into the dictionary if the value exists.
We could do this through some metaprogramming constexpr type checks.
For example, if the type in our C++ representation was not an
Optional, we can skip the has_value check.
Instead of doing that, change the IDL of the result dictionaries to
annotate these members so that the IDL generator knows this
information up front. While all current cases have every single
member returned or not returned, it is conceivable that the spec
could have a situation that one member is always returned (and
should get marked as required), while the others are optionally
returned. Therefore, this new GenerateAsRequired attribute is
applied for each individual member.
