Necko mode

Added: Lars Throop - Date: 23.01.2022 14:13 - Views: 12532 - Clicks: 1595

This is a dedicated to the de issues involved in making necko work under electrolysis i. In the long term, we do not want to allow any network connections from child processes for security reasons we may enforce this via operating system mechanisms. In the short term, we are more concerned with memory footprint and correctness. HTTP requires both caching and NSS, which are both memory-heavy, and it also uses cookies and auth, which require a single central database. So HTTP will need to be centralized in chrome immediately. FTP and gopher, if it's still supported will initially continue to run unmodified in child processes as an interim step.

Eventually they too will need to do network traffic solely in chrome. Web sockets will also need to be modified to run only in chrome. But this is for "Stage 2". There will also be IPDL traffic for notifications, cancellations, and probably other things. The most common case of necko usage under electrolysis will be network requests that necko mode in tab process, and are serviced by the parent. But it is important to realize that there are actually three logically different types of network request:.

This is both for performance reasons, and to avoid tricky issues that can come up with sync messaging. In particular, the child necko mode avoid doing sync requests to the parent to get channel state information, as the parent channel may have diverged in state. The child channel must instead cache all the state info that is needed to answer any queries from necko client code. Lucas suggested that IPDL parent actors should take measures to validate data passed to them by children, in case the latter have been compromised ex: validating that strings are actually UTF In necko's case, that should mainly be the URI and other data for the initial request, but keep in mind for other IPC exchanges, too.

The necko e10s code is currently turned on by default in the e10s necko mode. Depending on what you're trying to do, you'll either be running xpcshell tests or the remote tab demo a. Running xpcshell tests is quite lightweight text-based, and fewer XPCOM things to load, so fast to run on a remote machine over ssh, etc. Develop with xpcshell when you can unfortunately some important features--like load groups, notifications, etc. NOTE: the xpcshell tests currently by default do NOT run the e10s version of necko; instead they run the "each process gets the full necko stack" version.

This is both because we are still making sure that the xpcshell tests all work correctly on the child-side with necko unmodified bug before we try to test them against the experimental code, and because it is quite certain that many of the existing tests will fail if we try to run them against our buggy, incomplete e10s necko code.

You will want to turn on the e10s code if you're trying to test it. You may also want HTTP logging to work :which is currently broken. I do not yet have a fix for HTTP logging for test-ipc. All necko e10s work should be grouped under one of these two tracking bugs. They are now superceded by the various bugs that have been created for them, but I'm keeping them around for reference.

Please update the bugs, not these notes unless you feel like doing both :. HTTP headers will need to be parsed first in the chrome process--so things like auth, cache directives, cookies, etc. We will also need to provide some or all headers to the content process, via IPDL. The current architecture shifts out the original channel and replaces it with a channel to the new destination. The download manager should live in the chrome process. The chrome process is responsible necko mode displaying "Where do you want to save this file?

Issues arise in this architecture as I understand it because currently necko actually primarily resides in content processes.

In the ideal world, necko would live in the chrome process entirely and would proxy requests for content processes. Content processes would "subscribe" to the kinds of content they're able to handle for a given request, and if no handler is subscribed, the download manager should be invoked. Unlike the regular HTTP cache, which will be invisible effectively to the content process, the app cache will be visible to the content process, which needs among other things to parse HTTP headers to see if data needs to be cached.

Firebug, for instance.

We suspend Channels from the Download manager, and also when plugins don't consume arriving Channel data quickly enough. Also HTTP auth? Right now the Channel has callbacks which can be used to get originating window. We'll need to make this work with e10s, possibly by including window info in chrome Channel when we create it during AsyncOpen. Jump to:search. menu Personal tools Log in Request. Namespaces Discussion. Views Read View source View history.

This was last modified on 24 Mayat Privacy policy About MozillaWiki Mobile view.

Necko mode

email: [email protected] - phone:(114) 464-9866 x 2625

Necko: Electrolysis de and subprojects