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.
The spec doesn't have any exact steps here, it just notes:
The user agent MUST evict all expired cookies from the cookie store
if, at any time, an expired cookie exists in the cookie store.
Here, we implement "at any time" as "when a cookie is retrieved or
stored".
I hereby declare these to be full nouns that we don't split,
neither by space, nor by underscore:
- Breadcrumbbar
- Coolbar
- Menubar
- Progressbar
- Scrollbar
- Statusbar
- Taskbar
- Toolbar
This patch makes everything consistent by replacing every other variant
of these with the proper one. :^)
https://tools.ietf.org/html/rfc6265#section-5.3
This includes a bit of an update to how cookies are first parsed. The
storage spec requires some extra information from the parsing steps than
just the actual values that were parsed. For example, it needs to know
whether Max-Age or Expires (or both) were specified to give precedence
to Max-Age. To accommodate this, the parser now uses an intermediate
struct for storing this information. The final Cookie struct is not
created until the storage steps.
The storage itself is also updated to be keyed by a combo of the cookie
name, domain, and path.
Retrieving cookies was updated to use the spec's domain-matching
algorithm, but otherwise is not written to the spec yet. This also does
not handle evicting expired cookies yet.
Setting the year to NumericLimits<unsigned>::max() resulted in the
following datetime: -2-12-31 00:00:00.
Instead, set the latest datetime to the last second of the year 9999.
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.
Note: the default expiry time should be the "the latest representable
date". However, DateTime::from_timestamp(NumericLimits<time_t>::max())
isn't feasible due to the for-loops in LibC's time_to_tm. So instead,
this just sets the date to the maxium year.
This adds storage for cookies that maye be set via 'document.cookie' in
JavaScript or the Set-Cookie HTTP header. For now, it parses only the
name-value pair from a set-cookie line, but does not parse optional
attributes.
Currently, storage is ephemeral and only survives for the lifetime of
the Browser instance.
By setting the parent of the JS console, DOM inspector, view source and
download windows, they will be destroyed automatically when the main
browser window is closed.
Fixes#2373.
Added input hook into console widget to allow input to be captured and
sent to the external JS console via IPC.
Output from the external JS console is fed into the console widget
via handle_js_console_output().
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
This is a little bit messy but the basic idea is:
Syntax::Highlighter now has a Syntax::HighlighterClient to talk to the
outside world. It mostly communicates in LibGUI primitives that are
available in headers, so inlineable.
GUI::TextEditor inherits from Syntax::HighlighterClient.
This let us to move GUI::JSSyntaxHighlighter to JS::SyntaxHighlighter
and remove LibGUI's dependency on LibJS.
This patch adds an IPC call for debugging requests. It's stringly typed
and very simple, and allows us to easily implement all the features in
the Browser's Debug menu.
Frick it, let's just enable this by default and give ourselves a reason
to improve things! Some things are broken, and there's a bit of flicker
when resizing, but we can do this.
This drastically improves our web browsing security model by isolating
each tab into its own WebContent process that runs as an unprivileged
user with a tight pledge+unveil sandbox.
To get a single-process browser, you can start it with -s.
Now that WindowServer broadcasts the system theme using an anonymous
file, we need clients to pledge "recvfd" so they can receive it.
Some programs keep the "shared_buffer" pledge since it's still used for
a handful of things.
