This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
Read this as a first step. It's the easiest first step I could think of to
both reduce the quantity of stuff we serialize and ship to the worker as
well as to spread it out over multiple messages.
Anyway, the motivation is pretty simple. Taking a look at a session store
file on disk, a giant chunk of it is base64 encoded tab icons. I suspect
that in many cases these are not distinct. For my session store it's about
90% the same repeated searchfox icon over and over.
So what I did was I changed the "image" property of the tab to be a reference
into a deduplicated cache of objects (in this case strings). Whenever the tab
icon changes, we drop a reference to its cache entry and add a reference to a
new or existing entry. Each time a cache entry is added or deleted, we send
a message to the worker to update its own copy of the cache. This does
represent a memory hit, since the cache is maintained on the worker as well as
the main thread, but I think it's going to be minor, and it's only in one
process. Given the deduplication there is the possibility of an overall
reduction in memory use? This needs more testing.
Once it comes time to write the session data to disk, we send the payload with
"image" entries referencing IDs in the cache. When the worker gets the message
to write, it adds its internal cache to the object, which it then serializes
to JSON and writes to disk as usual.
When reading the data off disk, we take the cache items that had been written
and we slowly populate the worker's internal cache with them (to not overload
during startup with a giant message). And when populating tab icons of tabs in
the tab strip, we look up the image in the main thread copy of the cache. Also,
if we cannot find the entry, we assume that the image is just the raw
representation of the image. This ensures that we interpret a sessionstore file
from prior to this patch correctly.
Additionally, since we have the cache duplicated on both threads, if the worker
gets terminated for some reason, we rehydrate it with the snapshot of the cache
from when we noticed it was a problem.
I suspect some tests will need to be updated, or maybe many tests. However I
wanted to throw this patch past someone with more knowledge of the session
store's inner workings before throwing a bunch of time at that.
Differential Revision: https://phabricator.services.mozilla.com/D114196
The reported error happens because `.parentNode` can be a document,
which doesn't implement the Element interface. Using `.parentElement`
solves this issue.
And while I'm fixing this: move the logic behind the menu ID check, so
that the logic is not unnecessarily run for non-pageAction contextmenus.
Differential Revision: https://phabricator.services.mozilla.com/D116138
To resolve this bug, we need page action icons and semantic page action nodes to be separate. That way, we can apply filters to the icons without also filtering the nodes' outlines. This means the semantic meaning of the page action button must move up a level, to the enclosing hbox. This means reverting bug 1482025, so I'd like a11y review on this patch.
Differential Revision: https://phabricator.services.mozilla.com/D114131
To resolve this bug, we need page action icons and semantic page action nodes to be separate. That way, we can apply filters to the icons without also filtering the nodes' outlines. This means the semantic meaning of the page action button must move up a level, to the enclosing hbox. This means reverting bug 1482025, so I'd like a11y review on this patch.
Differential Revision: https://phabricator.services.mozilla.com/D114131
