10.4 will not build Electrolysis without writing support for issue 66, and based on some code I've been reviewing, possibly not even then. There are lots of workarounds for threading problems in 10.6 which will almost certainly plague 10.4 and 10.5, quite probably other problems with the older operating systems, and then potential endian issues with serializing data over IPC. If Mozilla had gotten e10s working for Firefox 4 as originally planned, there was a good chance we could have made it work then since Mozilla still supported 10.5 and most of the code was still appropriately endian-agnostic, but they didn't, and we won't. 10.6 support is likely to end in the very near future as well, which dooms us further.
As a result, I'm declaring now that in its current state, Electrolysis will not be supported by TenFourFox. I don't think it can be done on our older OSes in a satisfactory fashion, let alone by one guy, so if and when Mozilla makes it mandatory that's where source parity will end. Assuming no breathtaking technical breakthrough on my part, if it appears to be imminent after the 38ESR diversion (which is my current estimate), we go to feature parity at the end of 38ESR.
Remember, feature parity does not mean the browser stops developing -- it just stops mirroring an official branch of Firefox. By 38 we will have the strongest suite of HTML5 and ECMA6 support available for OS X on PowerPC, including <picture> support and WOFF2 webfonts, and I'm still working on getting IonMonkey PowerPC complete as well as our MP3 playback module. Should I cut support there, I also intend to continue backporting relevant security and stability fixes to the extent they apply, as well as necessary updates to our encryption suite so that HTTP/2 and TLSv1.3 are fully supported. Suitably maintained, we should still have a top-tier layout engine for at least one to two years after the end of ESR38, and a functional one for some time after that. Watch this space.
The release of 31.3.0 got delayed to December 2, which is annoying, because I spent the weekend building it instead of watching the calendar. Fortunately, no patches relevant to us so far have landed afterward, so these already-built versions will be uploaded later this week assuming there are no last minute changes. Happy Thanksgiving.
This comment has been removed by the author.
ReplyDeleteWould you mind sending me the crash reports of the crashes you get with WebKit?
ReplyDeleteI'm maintaining WebKit primarily for myself and I find it's really stable for what I do with it (I'm using it for all web browsing I do at home) - and the most frequent crash I had in the past few months (and some others) should be fixed in 537.78.2_2.
There are some known Safari crashes that don't seem to have anything to do with WebKit directly - I can't fix those unfortunately. If you'd send me the crash reports (~/Library/Logs/CrashReporter/Safari*.crash) I could tell you if your crashes are of that class, which I can't fix.
At the Leopard WebKit project page you may add a message to issue 77 with the crash report(s) attached (https://code.google.com/p/leopard-webkit/issues/detail?id=77).
ReplyDeleteI forgot to mention that in the case of using the WebKit application the crash reports should have been saved as "~/Library/Logs/CrashReporter/WebKit*.crash".
(By "WebKit" you have meant WebKit from the "Leopard WebKit" project, didn't you?)
I don't think the endian issues in e10s are that bad. I've been sometimes running with e10s enabled on my powerpc Linux builds from mozilla-central and things generally work. I find its slower than single-process mode and sometimes tabs stop responding but these might not even be endian or ppc specific issues.
ReplyDeleteI hope you're right about the endian problems (though some of the int64 bugs I've fixed don't make me as confident), but we've still got the issues about 10.4 and 10.5 which have some well known threading problems we've run into before.
DeleteInteresting that it's slower too, though always hard to judge on a very early release, of course.