Functioning like Chrome in rendering and page features doesn't mean Firefox has to behave like Chrome in the UX. For example, why gut the ability of people to skin and customize their browser as they see fit? Why is Mozilla involved in a running battle against users who want the tabs below the address bar? Why entirely prevent us from sideloading extensions instead of letting us turn the ability on and off?

I guess that for the first two the answer is in part managing complexity

and the last one is to reduce attack vectors

Ah yes, the good old walled garden approach.

Not very "open", is it?

i mean I don't like it either, but I do believe them in this instance that it's mostly in service of not letting installers just sneak in a toolbar

I think that this is misguided. If a malicious installer sneaks in toolbars it can also install a keylogger/send all of your data to a server/install a firefox fork with the toolbar preinstalled/etc.

If anything this kind of thing only hurts the users that know what they are doing (such as someone wanting to install a 3rd party addon or someone wanting to install addons via nix).

> If a malicious installer sneaks in toolbars it can also install a keylogger/send all of your data to a server/install a firefox fork with the toolbar preinstalled/etc.

If it's totally rogue malware, sure.

The toolbars, on the other hand, were coming from companies like Oracle that operated entirely within the bounds of the law.

Installing a firefox fork is also within the bounds of the law.

The anti-IE generation is mostly to blame for that, they ended up adopting the behaviours they criticized so much.

It is indeed sad how people who hated IE so much have now enabled the next IE not once but twice (Chrome on the desktop, Safari on mobile).

IE made life miserable for developers. I am not sure we would have cared if it were not moribund.

Nope it was pretty great actually, then Microsoft thought they had won the war.

Initially, IE6 was much better than the competition. But it was still buggy, and had some very weird rendering behavior. Over time, other browsers became much less buggy, but IE6 was still around. That's how IE6 came to be viewed, in retrospect, as a very buggy browser.

Should we have a look at Chrome's bug database?

Chrome was the first browser to adopt an evergreen model, where updates were installed automatically. While Chrome (and Firefox, once they adopted this model) have had many bugs over the years, when they fix a bug everyone gets the fix. The problem with IE6 (and later, up until Edge) was that bugs were here permanently: something that web developers needed to work around for as long as anyone was still using that browser.

Should we go through all open tickets that are open since 2013? Or start even earlier with the "forced closed" ones?

IE6 had major compatibility bugs that were never going to be fixed. For example:

* It considered width to include border and padding, when the spec and other browsers did not: https://www.jefftk.com/p/the-revenge-of-the-ie-box-model

* Floated block elements would get their margins doubled, so people would typically use padding instead.

* Its implementation of height was more like min-height.

While I'm sure Firefox and Chrome have open bugs that are older than that, I'd expect them to be much less important than these critical misinterpretations of CSS.

Well, I can track down examples of similar critical bugs for Chrome, but then again, I guess it would just move the goal posts to another defence round for Chrome.

You think Chrome, Firefox, Edge, or Safari (the main evergreen browsers) have bugs that have been open for years and are as critical as considering an element's width to include its border and padding? This misinterpretation of the CSS specification was something that essentially all front-end developers had to work around for 10+ years!

Yes I think so, all of them have bugs that web developers have to work around, again should we look at Chrome's bug database or maybe AdWords has a better source of information for such workarounds?

If you want to point to an example bug, I think that would help me understand your point, yes.

(To give a sense a sense of the scale I think we're talking about, this would be a bug that, say, more than half of web developers have to understand and work around in a typical month)

My point it that you are tainted by your employer, so this discussion is worthless, no matter what I come up with.

Whereas Chrome makes life miserable for users not using Chrome, because of the sheer amount of non-standard, Chrome-only features used in current webdev.

Which non-standard features?

Using google properties is a bit of an easy jab, but:

Youtube using polymer/shadowdomv0 and absolutely destroying performance on Firefox is a an easy example. Google Earth used non-standard APIs.

Otherwise, have a quick search for "non-standard" on MDN, and see how many of those Chrome implements.

But both of those are Google products. Yet here we are in a thread blaming an entire generation of web creators and users.

Ah, so only when Microsoft does it is bad, but when that generation worships Google for doing the same it is suddenly alright.

Make better and paid/subscription based(!) dev tools, instead screwing the UI and disabling add-ons. People are buying jetbrains products even though free ones exist.

I do use firefox but all the auto-update features are off on desktop. On mobile I am/will be stuck with 68 forever, I suppose as well.

Perhaps FF developer edition was meant to test the waters for this approach? Do web people actually use that? I never got to the point of making it part of my process, but I'm not doing enough web to really have a process.

In any case, a dev browser can only be relevant if it's representative of end user browsers. The history of browser wars has shown that a superior dev experience can be a decisive factor in winning users, but it can never be more than a supporting role.

These days a far more plausible dev level monetization angle would be Mozilla's unique position as the origin of Rust. Spin out a Rust subsidiary that sells service and perhaps also some premium tooling/SaaS in the open market while doing work on Rust/Servo/FF for a nominal fee that allows both sides to keep the lights on.

But that (just like paid browser dev tools) would be B2B and apparently Mozilla Corp completely fails to see itself as a B2B actor outside of consumer eyeballs deals like the Google deal and the increasingly outbrainy start tab fillers.

But failure to go that way is hardly surprising. Where would the business skillset come from when the entire organizion outside the tech teams has more in common with the great money furnaces of Wikimedia than with anything else?

The only way I can see for that kind of transition to go well would be some form of merger/acquisition with someone already existing in those fields (consultancy and/or tooling). "you take the engineers, we'll be buying services". But the successful ones would be very reluctant to suddenly load themselves with the entirety of Rust. It would probably take someone owner-managed who brought a decent amount of idealism into the equation. Total number of candidates might amount to zero.

This is the main thing I’m concerned with. Instead of adhering to an open standard, everything becoming ‘whatever google says goes’.

The Firefox bug report for a websocket message inspector was opened 7 years ago. It took 6 years before it got implemented.

Its no wonder they lost marketshare among developers.

I can find similar examples in Chrome, yet that doesn't detain some devs to worship it.

Yes, but Chrome is considered the default. If something doesn't work in Chrome, I will get in trouble with my boss for implementing it.

If something doesn't work with Firefox, we tell the users to use Chrome.

So just like IE 6, some things never change in spite people telling otherwise.

Agree with this sentiment 100% - it’s not better, it’s just less evil.