Live data from Hacker News

Mozilla’s Uncertain Future

civilityandtruth.com

311–320 of 405 posts

Re: Mozilla’s Uncertain Future

#311

Earlier quoted context omitted.

Hasn’t the quantum project been successful? It seemed like project accomplished to me. https://news.ycombinator.com/item?id=24164058 It’s not like they binned servo and decided not to use it improve ff. It did improve ff. They seem to have decided that’s done and finished now. And there’s no longer any need to work on it - whether that’s a wise move or not is obviously up for debate.

Quantum was just one of the milestones, albeit an important one. Servo continues to develop and pass on many more features to Firefox. Shutting it down is basically shutting the major pipeline of progress that has gotten so many of us excited over Mozilla in the past several years. The decision does not augur well for Firefox and Mozilla.

I concur, it’s quite insane. All their initiatives brought back tiny, tiny figures compared to the google search deal. And that deal is so profitable because Firefox still has a decent market share.

Torpedoing the technological future of their browser is bound to reduce that share, at which point Google will likely offer much less money.

They are basically shooting their one trick pony in a leg, deliberately. It’s.... not smart.

Re: Mozilla’s Uncertain Future

#312
post #266
post #263

Earlier quoted context omitted.

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 bro…

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.

Re: Mozilla’s Uncertain Future

#313
post #303

Earlier quoted context omitted.

>It’s only relatively recently with Electrolysis and Firefox Quantum that Firefox has regained a technical parity or superiority. And those changes depended on specifying a proper UI and Extension API which is the reason why the browser is no longer so customisable. No, they did not. Electrolysis was around before WebExtensions. Sure, Electrolysis wasn't backwards compatible and a lot of existing extensions had to re…

I noticed the same thing when the certificate fisasco happend: There was this one special XPI file they pushed via Normandy and I installed it manually (it was posted in some discussion forms) to get my extensions running again without restarting Firefox. If one unzips this tiny XPI, one finds javascript code which can directly install a certificate into the master store. So there is indeed a very powerful extension…

>Probably all the old stuff can be brought back easily.

Not anymore. They removed/replaced a ton of stuff that only was used by extensions at that point. That might lower their maintenance burden, but for the most part it really was interfaces and code that hadn't been touched since the 1990, so it wasn't like it was a huge maintenance burden before.

That means it wouldn't be that easy to bring back the extension system where the old extensions would be able just run unmodified. But it would be easy enough to bring back newly created old-type extensions or modify existing old-style extensions to use whatever is present now instead of the old stuff that got removed.

But then again, old-style extensions had to check anyway if a new major release broke anything, and usually it did break some stuff for some extensions. It was the cost of doing business. Jetpack/WebExtensions could help with that; if you extension was simple enough to fit within their APIs.

In fx60 (esr) the removal of these "old" interfaces and other things hadn't progressed much yet, so I was able to just git-revert most of the removals that affected the extensions I care about and that was enough to run those extensions again without obvious bugs.

Re: Mozilla’s Uncertain Future

#314

Earlier quoted context omitted.

So would anyone care to explain how vimperiator style customization is possible with webextensions? Newer Firefox explicitly does not support that level of customization.

Never used Vimperator, but I'm happily typing this message in an embedded Vim using SurfingKeys on Firefox 97.

Yes I also use the various attempts at vim emulation in the newer Firefox versions. The attempts are commendable given the limitations of the APIs. None of them are anywhere near as powerful in terms of vim like behaviour. If you never used any of the really powerful old style extensions you have no point of comparison.

But this is irrelevant. Previously extensions could do anything to alter Firefox. Webextensions are deliberately limited in scope - this is explicitly stated by the Firefox developers. So to say extensions as well supported as ever is factually wrong. The support is much more limited now.

Re: Mozilla’s Uncertain Future

#315

Earlier quoted context omitted.

> It's soo more than that. They'd destroyed all the old UI in favor of Chrome-style HTML+JS instead of platform-native XUL It's a browser, the entire purpose of a browser is rendering HTML+JS quickly and efficiently. XUL primitives are not, on average, faster or more "platform-native". >They added all sorts of weird commercial initiatives to someonething that was supposed to be ... nonprofit You understand the proble…

> XUL / XPCOM had significant, tangible problems. Significant problems that could have been fixed > XUL primitives are not, on average, faster or more "platform-native". At least on Windows they mapped to their native components. Sure spacing and a few other things were a little off (maybe because it mapped to GTK? I don't remember) but the look and feel then was vastly superior than the Electron-looking garbage that…

>The XBL document mentions more systemic problem but I maintain that they could have been fixed iteratively ... >Significant problems that could have been fixed

It is not like the Firefox developers do not understand the value of iterative change. That was after all the basis for Project Quantum. If this were true, they would have done it.

But I'll let a Mozilla engineer explain this instead:

https://dblohm7.ca/blog/2015/08/30/on-webextensions/

https://dblohm7.ca/blog/2017/11/16/legacy-firefox-extensions...

Re: Mozilla’s Uncertain Future

#316
post #153

Earlier quoted context omitted.

>The reason Firefox has lost market share in my opinion is because: My opinion is that none of those actually matters. The "one" single reason Chrome won market share was the same playbook how Google Search Engine Started. Speed. I watched hundreds of users, given the choice, or doing so themselves installing / using Chrome by their own selection. It was faster. The user experience was far better. You could advertise…

> I watched hundreds of users, given the choice, or doing so themselves installing / using Chrome by their own selection. I don't know who you are, but having watched “hundreds of people” installing a web browser sounds a bit dubious… Personally, I have discussed with a few dozens of websites users and most of them would answer the question “what web browser do you use” with “Google” no matter if they were using Chro…

I remember seeing non-technical people back in the days making the switch to chrome because it was faster indeed. Firefox had to do some catch up, and words of mouth didn't work in Firefox's best interest for quite some time.

Re: Mozilla’s Uncertain Future

#317
post #40

Personally and strictly my own ignorant and informal opinion, Firefox and by extension Mozilla Corp. was doomed the moment it decided to compete with Chrome by being more like Chrome. Firefox built its userbase by being different than the dominant browser, then decided the only way to not die was to be exactly like the dominant browser except with less icky behind-the-scenes privacy behavior. That was a fundamental m…

> the constant deprecation of power features and customizability They made ONE switch to a superior and standard extension model, and HN loses its minds. Do you really think you're in the majority here? Making it a more secure, faster and just better browser is just the only way forward. Without that Firefox would just be slow as hell, wouldn't play YouTube or Netflix videos, and not have any extensions left because…

it's definitely not superior seeing how tree style tab is still somewhat broken (which is the number one reason for anyone to switch to firefox)

Re: Mozilla’s Uncertain Future

#318
post #40

Earlier quoted context omitted.

> the constant deprecation of power features and customizability They made ONE switch to a superior and standard extension model, and HN loses its minds. Do you really think you're in the majority here? Making it a more secure, faster and just better browser is just the only way forward. Without that Firefox would just be slow as hell, wouldn't play YouTube or Netflix videos, and not have any extensions left because…

> Without that Firefox would just be slow as hell, wouldn't play YouTube or Netflix videos, OK, this is just plain wrong IMO. Speed is a major thing for me and I never had issues with it, even with 400+ tabs. I can go as far as understanding that not everyone was as lucky as me but it seems the speed issue is given too much weight. > and not have any extensions left because no one wants to create an extension from sc…

There was definitely a period were everyone (including me) was complaining about Firefox' speed.

Re: Mozilla’s Uncertain Future

#319
post #153

Earlier quoted context omitted.

>The reason Firefox has lost market share in my opinion is because: My opinion is that none of those actually matters. The "one" single reason Chrome won market share was the same playbook how Google Search Engine Started. Speed. I watched hundreds of users, given the choice, or doing so themselves installing / using Chrome by their own selection. It was faster. The user experience was far better. You could advertise…

> I watched hundreds of users, given the choice, or doing so themselves installing / using Chrome by their own selection. I don't know who you are, but having watched “hundreds of people” installing a web browser sounds a bit dubious… Personally, I have discussed with a few dozens of websites users and most of them would answer the question “what web browser do you use” with “Google” no matter if they were using Chro…

This forum isn't some obscure backwater.. A large chunk of all the world's tech wizards congregate here during boring meetings, bathroom breaks, etc.

If someone claims to have done some work with tech, chances are they're telling the truth

Re: Mozilla’s Uncertain Future

#320
post #312
post #266

Earlier quoted context omitted.

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 an…

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.
Post reply on HN