"Adopting Google's engine" is an interesting turn of phrase. There's still more Apple-contributed code at the core of Blink than Google code. It's not like Google did a full rewrite when they forked Webkit to create Blink.
When you think about it, at this point the Chromium project (including the Blink engine) has "contributions" in some sense or another from Microsoft, Google, Apple, and KDE. Certainly, it's a project mostly run and stewarded by Google employees in their off-hours; but there are actually a lot of interests involved! (Especially now; I expect Microsoft has likely switched their Edge browser engineering team to to writing PRs for Chromium.)
I don't think your claim is entirely accurate. Google's blink and Webkit are probably very different after all these years. And even at the very beginning of Chrome, Google had to make quite a bit of changes because of Chrome's process / sandboxing model , which was the main reason for the fork later (also related adaptations for skia graphics engine and v8) See [1].
Besides html rendering is only a portion of what makes a browser. considering today's Chromium codebase as a whole, I would guess probably >80% of it was written by Google engineers (and certainly not in their off hours). Still I would consider it a successful open source project as now it has quite diverse contributors, (Non Google contributors now amount to ~30% [2], biggest are Microsoft, Igalia, Intel etc.).
To clarify: I implied that Chromium is run and stewarded in Google employees' off-hours, which is different from the project being developed in Google employees' off-hours.
Of course Google pays people to work on Chromium. But do they pay people to decide what makes it into Chromium?
If so, that's a very bad look for a FOSS project. One of the central points of having a separate standalone community-driven FOSS project in the first place (rather than a corporate "source-available and we accept PRs if you assign us the IP" project), is taking steering of the project away from the corporation that created the code, and placing it instead in the hands of the community. If Google employees serve in their capacity as Google employees as directors for the Chromium Project — and so Google can tell its employee-maintainers to reject a PR from Chromium because it's not good for Chrome — then how could a browser vendor producing a competitor to Chrome based on Chromium, trust the direction of Chromium to do what's best for all Chromium-based projects, rather than just Chrome?
I assume this is not the case; that Google employees not only don't direct the Chromium Project with backroom Google-internal decision-making, but are restricted legally from so doing. Though I can't find anything on the Chromium Project site to support that assumption...
I'm not sure I understand why you think Chromium is supposed to be community driven. Chromium is an open-source project that has a lot of Google and non-Google contributors (for example, Microsoft), but all of the main decision-makers are working on Chromium on behalf of their companies, and the majority of decision-makers are employed by Google.
I don't think Chromium is that kind of open source project. It doesn't seem that having the FOSS community leading the direction of dev is something they do. If you read some of the docs it seems that Googlers have special privileges and it's quite intertwined.
> If so, that's a very bad look for a FOSS project.
As much as I don't like to see Google having so much control over the dominant Web engine out there, being "community-driven" is completely orthogonal to FOSS, and Chromium is very clearly a Google project. You even have to sign a CLA before you can contribute to it: https://www.chromium.org/developers/contributing-code/extern...
As far as I can see the bigger problem isn't the code but a viable ecosystem, somewhere customers can go if Google doesn't behave. Let me explain:
As long as Firefox is alive and kicking Google cannot kill ad blockers on Chrome as they realize that will create an enormous backlash, massive PR and users flocking to Firefox.
Once Firefox is gone the network effects will be strong enough that they can eventually kill adblocking and people will be stuck with Chrome anyway.
Blame it on regulations or big media or whatever but I am certain they will do it if they get a chance.
Chromium source code might still be available but will not work on Gmail or Google Docs or Netflix, only on enthusiast websites :-/
Ad blockers are already dead on Android Chrome. I wish more people would use ad-blocking browsers, perhaps Firefox, but Fenix is somewhat slower than Chrome, and is a software train wreck of bugs.
What bugs? Ff had an upgrade not long ago where they made it difficult to use extensions, and the UI has been made worse (or I'm just old and set in my ways), but bugs? It just works. If it is slow, I never noticed.
I'm using Firefox Nightly, but many of the issues are present on release too:
- Saving images doesn't send the cookies, so you can't save images gated behind a login. (over 1 year old, not fixed, #17716)
- Switching tabs (by swiping the address bar) sometimes shows the old tab's contents/interaction, with the new tab's address bar. (unsure if reported, I should report it.)
- The menu shows a "sign in to sync" or similar prompt. When I click it, the settings screen shows me as logged in. When I close the settings screen, the menu shows me as logged in. (#19657, possibly #19036 too)
- Reopening a tab moves it to the very top of the list, before your oldest open tab. (fixed in nightly, #10986)
- Opening the tab menu scrolls you to a random place, rather than the currently open tab. (got fixed a few days ago. #20637, possibly #20960 too.)
- Reader mode randomly switches to default theme (fixed a few months ago, #17865)
The impression I get is that Firefox Mobile is shipping broken code and unwanted redesigns, and testing in production. Perhaps it's from a lack of engineering culture and management. Looking at issues like https://github.com/mozilla-mobile/fenix/pull/21038, I feel Mozilla is more interested in marketing, design, and analytics, than solid engineering. It's nauseating and depressing to see Mozilla fall so far.
It's funny, because I had the same "what bugs?" response as the parent. After reading your list, I realized that we just use the browser very differently.
I never save images from the web on my phone. I didn't even know you could switch tabs by swiping the address bar (I always open the tab menu). I'd never noticed the "sign in to sync" issue (just checked and I do see the same behavior you see), but it's just a harmless display bug IMO, that doesn't affect functionality. I've never seen the issue where opening the tab menu scrolls to a random place. I rarely use reader mode on mobile, and haven't noticed the theme issues.
The only one I've seen from your list is where reopening a closed tab moves it to the top of the list. But I do that so infrequently that it doesn't bother me.
Agree about Mozilla's engineering culture, in their mobile division at least. It's startling to think that literally the only alternative to a Blink monoculture on Android is a poorly-managed alternative. I now see myself as a holdout of Firefox on desktop, because the constant issues and quagmire of inexplicable UI changes compelled me to move to Brave on mobile.
As an example, the GeckoView ticket[1] that #17716 depends on has been constantly pushed back from v88 to possibly v93 or later over the past year. Being able to save an image that I am able to see on a webpage is what I consider basic functionality, but there does not seem to be much of an acknowledgement from the GeckoView team about its importance.
Another example is this[2] issue report I submitted. It was closed because they "couldn't address it", and even after providing a video showing the exact problem, my report was still ignored. The issue is that it does not matter whether or not they consider it a problem, because I do, and Chromium does not have the same problem. That only makes me more likely to choose Chromium over Firefox. Compound that a dozen times over, and for me, practicality wins out over principle.
I'm also worried about the long-term stability of their mobile division - not only because of Servo, but because issues related to the mobile team being understaffed and overworked had come to light in at least once instance in the past. Mobile web browsers are becoming far too important to get wrong in the present day, and after realizing this fact, I have to wonder why Mozilla's financial structure still prevents direct contributions to their development teams for Firefox, and why they are still using what resources they do have on far less important projects like Mozilla VPN or Relay.
I believe it was fixed a while ago, but I had pull to refresh disabled as a workaround at the time (when they finally made it configurable).
The pull-to-refresh implementation is a prime example of a buggy feature that was pushed out too early and only underwent sufficent testing only after it reached users. Some of the issues stemming from it still weren't fixed even a year afterwards, and they appeared in places as critical as Google's search results page.
> The pull-to-refresh implementation is a prime example of a buggy feature that was pushed out too early and only underwent sufficent testing only after it reached users.
I found out that this may not be accurate. Looking at https://github.com/mozilla-mobile/fenix/issues/21175, pull-to-refresh is simply absent from release builds, and only present in nightly builds. I wish it worked properly there though.
> Ff had an upgrade not long ago where they made it difficult to use extensions
You're talking about the old extension API, which was more of a "do whatever the heck you want" than an actual API, at that point in time it was pure technical debt - Mozilla was on a clock to remove it, or Firefox could never hope to stay competitive. It was a major roadblock in enabling modern sandboxing / isolation, performance improvements, developer productivity, etc.
Can't you see they had no other alternative? They wouldn't lose the few die-hard users that absolutely "needed" their browser to do insane shit, because there was no other (maintained, modern) browser that could do all of that; and the sympathy of the remaining 99.999% of their user base was at stake. Whichever option Mozilla would go for, the 0.0001% would get the same thing - the browser you were OK with, eventually stops getting updates, becomes irrelevant, and dies.
> If it is slow, I never noticed.
Luckily we can rely on tooling, such as benchmarks and profilers, to gather actual empirical data, and use that to guide our decisions. Whatever may not be a noticeable difference on your system, could have an enormous impact on another. I remember switching from Chrome to FF right around Quantum, because it was finally usable on my hardware.
No, I'm talking about only supporting "trusted" extensions (all 17 of them, last I checked) unless you use nightly and install extensions through a predefined list.
> Luckily we can rely on tooling, such as benchmarks and profilers, to gather...
> I remember switching from Chrome to FF right around Quantum, because it was finally usable on my hardware.
What are you talking about? I'm on an ancient phone and FF is far from slow. Is Chrome faster by X percent? Who cares. Installing an ad blocker is all one needs^W^W I need to surf the net easily.
How can Safari be a defender of the free web, when iOS explicitly prohibits any other engine? They are the new IE, in that they keep users hostage, but this time you can't even run a campaign to try to get users to use a new browser.
> How can Safari be a defender of the free web, when iOS explicitly prohibits any other engine?
If you look at my post above you'll see that I mentioned that this is more or less voluntarily :)
Maybe it is not their intention at all but as long as they exist it makes it harder for Google to pull the carpet underneath the free web and ad blockers in particular.
> They are the new IE, in that they keep users hostage, but this time you can't even run a campaign to try to get users to use a new browser.
No. Safari might be annoying in a number of ways, but the "new IE" title goes to Chrome.
IE became the old IE not because they lagged behind from the start but because they "innovated" new non-standard features until they had crushed competition, then stopped development until their market share was rapidly shrinking because of both Firefox and Chrome.
If you don't think Google will stop Chrome development as soon as they have crushed competition and "sadly" had to kill adblock then we have different views of Google.
(Please note: I don't think individual engineers at Google will push this agenda but I am fairly sure that "maximize shareholder profit" will over the course of a few months or a couple of years push this agenda with a weight that will easily crush even the most idealistic team. See WhatsApp for a case study of how a company and an engineering culture I loved was crushed.)
For phones/tablets, Apple doesn't want anyone using the web for apps, insisting on app store (and fees) for all transactions.
If Google came along with a deal to switch to Chrome, would modern, post-Jobs Apple go along?
Unless something had changed, they already accept cash to funnel Safari users to Google by default. And Google apps somewhat compete with Apple products.
So... why not more cash, and make Chrome Safari's guts?
Because Safari's guts weakens the web as an app platform and strengthens their App Store, a favorable outcome for Apple. Adopting Chrome as the guts of Safari would defeat that benefit, and it'd be pretty hard to regain it. Safari's current "guts" - Webkit - can veto web hardware APIs and slow down broad support for PWA features, things that would help web apps compete with the App Store.
Post-Jobs Apple is the company that was willing to replace Google Maps with their own app to gain more independent control from Google, and they were much further behind when they did that. I can't imagine that company ceding influence & control over their largest platform threat by ditching Webkit. That's my 2c of speculation.
To be clear, what I meant is that projects with open stewardship (which I believe the Chromium Project is? unclear from the project website) don't tend to want employees of companies, in their capacity as employees-of-companies to be directors/core maintainers for the project. Which is different from being regular developers on those projects.
Open-stewardship projects tend to be happy to accept contributions from companies; and they tend to be happy to accept the stewardship of individuals who happen to work at companies; but they don't want to be beholden to the interests of those companies in their direction, so projects with community/foundation stewardship don't usually allow companies to pay their employees for their time spent sitting on that foundation's board. (I.e. they let companies pay employees to write code, but they won't allow companies to pay employees to do the work of deciding whether that code belongs upstream.)
Instead, the software foundations that manage FOSS projects usually legally restrict corporations or their representatives from participating in their capacity as representatives of corporations in directorship/steering committees/etc. for the foundation. Instead, they expect/require each person with decision-making authority in the foundation to have their own individual voice—to not be just a sock-puppet of a company, saying whatever the company wants you to say. When you vote for things in the foundation, you have to be able to vote for the interests of the project itself, even if those interests are against the interests of the company you work for—without that endangering your job.
Which usually means that employees of such companies must do their foundation maintainership "off the books" of the company they work for, e.g. at non-work hours using non-work equipment. Just as if they were trying to avoid IP cross-pollution.
Source: worked at a company with an "open core" product, where the core was an Apache Software Foundation project, and most of the ASF project's maintainers happened to be employees of the company. Those people could push a PR to the ASF upstream for consideration from their work account, as a representative of the company; but they then had to don their personal-gmail-account, separate-profile, no-corporate-affiliation hat to handle the PR and discuss it with the other maintainers.
When you think about it, at this point the Chromium project (including the Blink engine) has "contributions" in some sense or another from Microsoft, Google, Apple, and KDE. Certainly, it's a project mostly run and stewarded by Google employees in their off-hours; but there are actually a lot of interests involved! (Especially now; I expect Microsoft has likely switched their Edge browser engineering team to to writing PRs for Chromium.)