This is in preparation for implementing JS scrolling functions, which
specify both x and y scrolling deltas. The visible behavior has not
changed.
Also, moved the "mouse wheel delta * 20" calculation to the
`EventHandler` since the JS calls will want to work directly in pixels.
This patch removes the following WebContent IPC calls, which are no
longer used:
- `Server::js_console_initialize()`
- `Client::did_js_console_output()`
With this patch, we now initialize the `WebContentConsoleClient` as soon
as the Page has loaded, instead of waiting for the Console Window to be
shown. This finally lets us see log messages that happened before the
window was opened! :^)
However, it is not perfect. Waiting until the page has loaded means we
lose any messages that happen *during* page load. Ideally we would
initialize the WCCC when the page *starts* loading instead, but it
requires that the page has a document and interpreter assigned and
accessible. As far as I can tell with my limited knowledge, this is not
the case until the page has completed loading.
The `WebContentConsoleClient` now keeps a list of console messages it
has received, so these are not lost if the ConsoleWidget has not been
initialized yet.
This change does break JS console output, but only until the next
commit. :^)
This patch introduces three new IPC calls for WebContent:
- `Client::did_output_js_console_message(index)`:
Notifies the client that a new console message was logged.
- `Server::js_console_request_messages(start_index)`:
Ask the server for console messages starting at the given index.
- `Client::did_get_js_console_messages(start_index, types, messages)`:
Send the client the messages they requested.
This mechanism will replace the current
`Client::did_js_console_output()` call in the next few commits. This
will allow us to display messages in the console that happened before
the console was opened.
`$0` is a helpful variable in other browsers' JS consoles, which points
to whichever DOM Node is currently selected in the DOM Inspector. And
now we have it too! :^)
ConsoleGlobalObject is used as the global object when running javascript
from the Browser console. This lets us implement console-only functions
and variables (like `$0`) without exposing them to webpage content. It
passes other calls over to the usual WindowObject so any code that would
have worked in the webpage will still work in the console. :^)
This is the IPC version of `Document::set_inspected_node()`, using a
node ID.
We return the inspected node's style properties as JSON, so that the DOM
Inspector can immediately display them.
This patch adds OutOfProcessWebView::run_javascript(StringView).
This can be used by the OOPWV embedder to execute arbitrary JavaScript
in the top-level browsing context on the WebContent process side.
Add `inspect_dom_tree` to WebContentServer and 'did_get_dom_tree' to
WebContentClient.
These two async methods form a request & response for requesting a JSON
representation of the Content's DOM tree.
This allows WindowServer to use multiple framebuffer devices and
compose the desktop with any arbitrary layout. Currently, it is assumed
that it is configured contiguous and non-overlapping, but this should
eventually be enforced.
To make rendering efficient, each window now also tracks on which
screens it needs to be rendered. This way we don't have to iterate all
the windows for each screen but instead use the same rendering loop and
then only render to the screen (or screens) that the window actually
uses.
Our "frame" concept very closely matches what the web specs call a
"browsing context", so let's rename it to that. :^)
The "main frame" becomes the "top-level browsing context",
and "sub-frames" are now "nested browsing contexts".
Instead of everybody getting their system fonts from Gfx::FontDatabase
(where it's all hardcoded), they now get it from WindowServer.
These are then plumbed into the usual Gfx::FontDatabase places so that
the old default_font() and default_fixed_width_font() APIs keep working.
This changes client methods so that they return the IPC response's
return value directly - instead of the response struct - for IPC
methods which only have a single return value.
This enables support for automatically generating client methods.
With this added the user gets code completion support for all
IPC methods which are available on a connection object.
The current ProtocolServer was really only used for requests, and with
the recent introduction of the WebSocket service, long-lasting
connections with another server are not part of it. To better reflect
this, this commit renames it to RequestServer.
This commit also changes the existing 'protocol' portal to 'request',
the existing 'protocol' user and group to 'request', and most mentions
of the 'download' aspect of the request to 'request' when relevant, to
make everything consistent across the system.
Note that LibProtocol still exists as-is, but the more generic Client
class and the more specific Download class have both been renamed to a
more accurate RequestClient and Request to match the new names.
This commit only change names, not behaviors.
The WebSocket bindings match the original specification from the
WHATWG living standard, but do not match the later update of the
standard that involves FETCH. The FETCH update will be handled later
since the changes would also affect XMLHttpRequest.
This patch removes the IPC endpoint numbers that needed to be specified
in the IPC files. Since the string hash is a (hopefully) collision free
number that depends on the name of the endpoint, we now use that
instead. :^)
Additionally, endpoint magic is now treated as a u32, because endpoint
numbers were never negative anyway.
For cases where the endpoint number does have to be hardcoded (a current
case is LookupServer because the endpoint number must be known in LibC),
the syntax has been made more explicit to avoid confusing those
unfamiliar. To hardcode the endpoint magic, the following syntax is now
used:
endpoint EndpointName [magic=1234]
This patch removes the IPC endpoint numbers that needed to be specified
in the IPC files. Since the string hash is a (hopefully) collision free
number that depends on the name of the endpoint, we now use that
instead. :^)
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
To protect the main Browser process against nefarious cookies, parse the
cookies out-of-process and then send the parsed result over IPC to the
main process. This way, if the cookie parser blows up, only that tab
will be affected.
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.
The previous handling of the name and message properties specifically
was breaking websites that created their own error types and relied on
the error prototype working correctly - not assuming an JS::Error this
object, that is.
The way it works now, and it is supposed to work, is:
- Error.prototype.name and Error.prototype.message just have initial
string values and are no longer getters/setters
- When constructing an error with a message, we create a regular
property on the newly created object, so a lookup of the message
property will either get it from the object directly or go though the
prototype chain
- Internal m_name/m_message properties are no longer needed and removed
This makes printing errors slightly more complicated, as we can no
longer rely on the (safe) internal properties, and cannot trust a
property lookup either - get_without_side_effects() is used to solve
this, it's not perfect but something we can revisit later.
I did some refactoring along the way, there was some really old stuff in
there - accessing vm.call_frame().arguments[0] is not something we (have
to) do anymore :^)
Fixes#6245.
