4 ms·

And there is a simple solution to that (poor multi-core utilization): go back to a one-window, one process model (go back, as in delete a lot of unnecessary cod

And there is a simple solution to that (poor multi-core utilization): go back to a one-window, one process model (go back, as in delete a lot of unnecessary code); forget the browser tabs - let the OS handle multitasking and let the window manager handle the windows.

randallu 13y ago
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?
bengoodger 13y ago
This is optimizing for the wrong thing (developer convenience vs. user experience). People like using tabs in their browser more than windows. This also ignores the other important benefit of mparch: sandboxing. The browser needs some elevated access but the page content does not.
- vy8vWJlco 13y ago
  I don't see developer convenience and user experience as mutually exclusive. If an application is simpler and more consistent, that can save time for both users and developers. (I also don't see how a one-process-per-DOM model prevents any other forms of sandboxing inside the browser. The OS doesn't understand webpages and cannot isolate them from each other - the browser does - so sandboxing pages is the browser's responsibility...)

randallu 13y ago

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?

bengoodger 13y ago

This is optimizing for the wrong thing (developer convenience vs. user experience). People like using tabs in their browser more than windows. This also ignores the other important benefit of mparch: sandboxing. The browser needs some elevated access but the page content does not.

vy8vWJlco 13y ago
I don't see developer convenience and user experience as mutually exclusive. If an application is simpler and more consistent, that can save time for both users and developers. (I also don't see how a one-process-per-DOM model prevents any other forms of sandboxing inside the browser. The OS doesn't understand webpages and cannot isolate them from each other - the browser does - so sandboxing pages is the browser's responsibility...)