2 ms·

The hard stuff isn't the window system/widget integration, it's having multiple processes open for the same domain (or iframes in different processes) and media

The hard stuff isn't the window system/widget integration, it's having multiple processes open for the same domain (or iframes in different processes) and mediating access to local storage/IDB/cookie jar/network cache/etc. It was only very recently that WebKit2 handled most of this stuff -- up until then they just had a single WebProcess (I think Safari on Mavericks is the first multi-WebProcess browser Apple have shipped). So it's a hard problem and isn't due to some lack of competence that Mozilla have been slow to adapt. FxOS is fully multiprocess afaik. Actually getting the rendered page image into a window owned by another process is easy: windows and X let you host HWNDs and Windows from other processes (if you choose to allow your WebProcesses access to the window server) or you could draw into a shared memory segment. The hard stuff is all of the regular browser hard stuff.

vy8vWJlco 13y ago
I can't accept your complicated worldview. Iframes, for example, don't need to be new processes. One process - one window - one DOM. The only new process should be the rendering canvas/window. An iframe, or any nested resources can re-use cookies associated with a window/process, including caching. In order to persist tokens/cookies/cache between processes you hand them their own copy when you spin them up and write them out to a common, re-usable place when you close, but for the most part I consider browser statefulness to be more like a flaw than a feature (I constantly clear my cookies, form data, and history). how about a "save session" button, rather than the default being to cache objects and cookies in some common blocking profile that only allows one session and that, when it crashes, it all comes down... If you really want to share, you wrap those services up in a library - which is closer to the present model - but you have to know that in doing so you are making it harder to isolate things when they fail... And isn't that what's wrong with most browsers?

vy8vWJlco 13y ago

I can't accept your complicated worldview. Iframes, for example, don't need to be new processes. One process - one window - one DOM. The only new process should be the rendering canvas/window. An iframe, or any nested resources can re-use cookies associated with a window/process, including caching. In order to persist tokens/cookies/cache between processes you hand them their own copy when you spin them up and write them out to a common, re-usable place when you close, but for the most part I consider browser statefulness to be more like a flaw than a feature (I constantly clear my cookies, form data, and history). how about a "save session" button, rather than the default being to cache objects and cookies in some common blocking profile that only allows one session and that, when it crashes, it all comes down... If you really want to share, you wrap those services up in a library - which is closer to the present model - but you have to know that in doing so you are making it harder to isolate things when they fail... And isn't that what's wrong with most browsers?