Why are most open source browsers based chromium as opposed to gecko? I would think much of the OSS community would be opposed to using google owned software.
There was supposed to be an alternate way to do it (running with ‘firefox -app’ or something), but it was poorly documented and constantly breaking in new versions, so I eventually gave up.
But, that is speculation, and I have no proof whatsoever other than tangential conclusions from Mozilla's blunders in recent years.
The only upside for Mozilla is that making Gecko available is the right thing to do. Which, for a nonprofit, matters, and I'm sure that having an Electron-equivalent is the kind of thing that would be considered cool by staff.
But there is the downside that it makes it easier to build browsers which would compete with Firefox for the shrinking niche that is "doesn't run Chrome or Safari". I guess you could make a case that such browsers would take at least as much share from Chrome as Firefox, maybe more even; but you could make the other case as well.
When you add the additional downside that it's probably many man-decades of work to do it at all, well, then it doesn't happen. Although the existence of GeckoView implies that Firefox and Gecko aren't as tightly coupled as they could be.
Chrome team was advcied very early in their development by none other than Android team to go for WebKit because it was easier to work with. Not Presto, not Gecko. So at least since back then, thud feature was at least somewhat on Apple's list of priorities. I'm not sure if it got carried over from KHTML, but if it did, they didn't break it intentionally.
Back in IE horror days I remember using Avant Browser. It used IE to provide fancier features like tabs. I never remember Gecko anywhere in discussion for being a platform to build on top of, except for other Mozilla projects (FFOS, Thunderbird) that Mozilla dropped sooner or later.
AFAIK the only thing around nowadays is GeckoView [2] for Android.
[0]: https://github.com/mozilla/positron [1]: https://mykzilla.org/2017/03/08/positron-discontinued/ [2]: https://mozilla.github.io/geckoview/
Even their own developers were disappointed when they changed direction.
I was working on replacing QtWebEngine(chromium) for Qutebrowser with Servo. It is very far from ready, most websites do not render correctly and JavaScript is very hit/miss with regards to updating the rendered view.
Simply put: Servo is not possible to use as a daily driver.
I often argue against purely natural language specifications in favor code based specs. I just don't think human language is nearly precise enough to write an adequate specification. Natural language words are incredibly polysemic and contextual. Look, for example, at how many meanings the word "break" has: https://www.merriam-webster.com/dictionary/break
Kolmogrov has long ago suggested that fully specified information distills down to a computer program: https://en.wikipedia.org/wiki/Kolmogorov_complexity, https://en.wikipedia.org/wiki/Minimum_description_length
The ideal language for a pure specification might be a mix of natural language and pseudo code with a pseudo test suit. However, if you are writing that, you might as well go one step further and write working testable code.
I like the concept of Literate Programming (https://en.wikipedia.org/wiki/Literate_programming) and its descendants of having code with extractable inline comments that auto generate documentation. I would argue that modern pull request based workflows that tie discussions to version controlled code changes are also the progression of this line of thought. A cleaned up version of these might make sense for a specification.
And I get some of the concerns. While natural language under specifies, reference implementations over specify. This is more of a problem with low level languages however. Modern high level languages are getting fairly close to a form of pseudo code. I fully agree that the reference implementations shouldn't contain or should hide, low level optimizations. I also understand that reference implementations can unduly tie specs to specific hardware, OSs and platforms.
But to me, over-specification is less of a problem than under-specification and it can be mitigated by labeling particular functions or blocks of code as implementation specific and not part of the spec.
Without spec written in code, the different implementations always have subtle incompatibilities. I see egregious versions of under-specification in government where horrendously vague specs are created in order to issue RFPs for getting software built. They usually end up with non working software at mind blowing cost.
People have this weird misconception that you are contracting out to build software. You are not. Building software is really easy. You press the build button or type the compile command. Building software has been fully automated for a while now. What is difficult is designing software and specifying what it must do. This is because there is a vast jungle of protocols, business flows, hardware and software platforms that need to be interacted in different ways for different needs. This is what needs to be specified and only computer code can do it adequately.
I wish that Mozilla adopted the chromium core. We really need a well funded non-profit managed release of the reference browser.
My only concern is that one ends up with something like TeX, written in a long-obsolete dialect of Pascal, requiring a translation layer to convert the source into a more relevant language (C).