SoylentNews is people
SoylentNews
Mozilla's Project Electrolysis aims to allow tabs and user interfaces to run in separate processes. It has been activated by default in recent nightly builds:
In current versions of desktop Firefox, the entire browser runs in a single operating system process. In particular, the JavaScript that runs the browser UI (also known as "chrome code") runs in the same process as the code in web pages (also known as "content" or "web content"). Future versions of Firefox will run the browser UI in a separate process from web content. In the first iteration of this architecture all browser tabs will run in the same process, and the browser UI will run in a different process. In future iterations, we expect to have more than one content process.
Developer Will Bamberg says the change will bring stability and security improvements. "There are three main reasons for making Firefox run content in a separate process: performance, security, and stability, Bamberg says. "The goal is to reduce 'jank' -- those times when the browser seems to briefly freeze when loading a big page, typing in a form, or scrolling. "In multiprocess Firefox, content processes will be sandboxed. A well-behaved content process won't access the filesystem directly; it will have to ask the main process to perform the request." Bamberg says "well-behaved" content processes needs to access much of the network and file systems. This would be much more restricted under the changes.
Former CEO of Mozilla Brendan Eich has announced a project called WebAssembly that could replace asm.js:
It's by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let's say. Today I'm pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.
What: WebAssembly, "wasm" for short, .wasm filename suffix, a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JS's semantics, in order to best serve as common object-level format for multiple source-level programming languages.
Who: A W3C Community Group, the WebAssembly CG, open to all. As you can see from the github logs, WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks. I'm sorry the work was done via a private github account at first, but that was a temporary measure to help the several big companies reach consensus and buy into the long-term cooperative game that must be played to pull this off.
Original Submission
(Score: 2) by jmorris on Saturday June 20 2015, @03:27PM
Actually Apple allows browsers into the App Store now. So you can get Chrome, Opera, etc. but not Firefox (yet) on iOS. On the desktop you can get both Chrome and Firefox along with a host of others. You just can't get IE anymore and probably won't have whatever Project Spartan ships as either.
But yea Apple isn't exactly downstream with WebKit anymore so if they decided to be difficult they could be the turd in the punchbowl so you have a valid point in that I ignored that possibility. However I doubt they would, if everyone else adds support for a new web standard they will follow. If they already have Moz Corp, Microsoft and Google on board expect Apple to start contributing soon.
As for Java, at this point I suspect Oracle would bust a nut at the offer to get a JVM into every browser even if it didn't include the whole 'Java' API set, only the VM and bindings to the DOM. Perhaps the fatal fight would be Google wanting their alternate VM?
(Score: 2, Informative) by Pino P on Saturday June 20 2015, @04:41PM
Actually Apple allows browsers into the App Store now.
The last time I checked, third-party web browsers for iOS, such as Chrome and Opera, were shells around the UIWebView or (since iOS 8) WKWebView class shipped with iOS. Both of these classes are Apple WebKit. You can't get Firefox because Mozilla doesn't want to dilute the "Firefox" brand with a browser not based on Gecko.
Gecko does not run on iOS because iOS policy prohibits Spidermonkey and all other third-party JIT engines. In iOS, all non-Apple code executes under a strict W^X policy. Only the system executable loader is allowed to populate an executable page. A desktop application can ask the memory manager to flip a page from writable and not executable to executable and not writable, and a JIT engine will flip a page after filling it with code. But this operation is forbidden to non-Apple executables on iOS. This means no HotSpot JVM, no CLR, no Google V8, no Google Native Client, and no Mozilla Spidermonkey.