IMO Firefox has just 2 things to beat Chrome: better add-ons (like treestyle tabs) and politics (made by Mozilla instead of an ads company). They are burning the first one.
Search companies -- formerly Google, now Yahoo and others -- pay Mozilla so that the browser defaults to their search engine. While it may not be a display ad, it's effectively funded by advertising.
Why? Does Chromium support Tree Style Tabs despite using WebExtensions? If that's the case, why would that not be possible for Firefox? Or would you switch to make a statement?
It wouldn't really be to make a statement. Chromium is a better browser but because of the powerful add-ons Firefox's overall experience is better. Take that away and there's no real reason to stay with Firefox unless you like their license and Mozilla as a company.
That's a pretty terrible idea. Your web browser is probably the most important piece of software to keep up to date, besides the OS for security reasons.
Mozilla's test pilot projects there serve to prototype proposed extension APIs. It's there to inform the design of what hooks are needed to make such an addon possible, so that it will still be possible in a world with only WebExtensions.
Are the APIs required to make TabCenter as a WebExtension guaranteed to work on FF 57? If not, temgo is still right, no? At least an argument could be made that the elimination of XUL should only happen when the current experiments can actually be implemented using the new model.
During 2016, Firefox had 53 code execution CVE reports.
Chrome had 2.
Firefox only has around 8% of the browser marketshare. Chrome sits between 44% and 60% depending on the source.
So it's not a case of Firefox being more popular and attracting more people to target it for hacks. It's just worse software.
And then there's just user inconveniences like how Firefox becomes extremely slow if you open multiple heavy tabs. e10s has yet to fix it, currently, if you enable it, it only opens 2 processes, one for the UI, and one for the rendering engine. So the UI itself might not slow to a crawl but all your tabs will still feel slow if you open heavy stuff.
Firefox also has a slower rendering engine. My eyesight isn't great and I browse web pages with zoom active in between 120% and 150% depending on pages. That makes Firefox behave extremely slow on some pages. It's particularly unbearable, on, say, slashdot pages with lots of comments.
For the same reason smooth scrolling is the first thing Firefox users disable in Firefox. Smooth scrolling works fine on Chrome. FF has never managed to implement smooth scrolling in a way that doesn't slow things to a crawl and makes the scrolling look like stuttering or low framerate.
People often rely on Javascript benchmarks to say "Hey firefox is as fast as chrome!!!11!!" but JS is only one part of what makes a browser fast or slow. What about the parts that actually render the page to something your screen can display?
> Firefox 57 should be at least equivalent to Chromium.
Chrome would have had to stop all development years ago for that sentence to be true.
And Firefox is less secure and slower because (drumroll, please...) the major architectural changes required to improve on those fronts is completely stymied by the desire to maintain backwards compatibility for addons. Firefox is at last forced to decide between being a bad but very extensible browser or a (hopefully) good but less extensible browser. IMO, the choice is pretty obvious.
But chrome is already a great and less extensible browser, which is the point. If chrome is great and less extensible, and Firefox is good and less extensible, there's little reason to use Firefox unless you just don't like Google.
So true there is way more to the browser than the java script engine. So I ran ye old browser showdown on my comp (Fresh everything). Firefox and Chrome are very similar in speed with Java benchmarks, but once you get into the "real-world" type benchmarks, Firefox was faster by a large margin and was almost 3x as fast as Chrome in some tests.
Each browser has it's strengths and weaknesses it seems, So I run all of them lol
For my day to day tab filled behemoth I have to use Firefox, any other browser can't handle the ~80 tabs I have open at once.
In fact me and my roommate have on going challenges on how many tabs we can keep open and up times of the browsers/OS's (He is on Win7). During our battles we have tried tweaking some things and using odd browsers and such, but to be competitive with one another we have to each use Firefox cause it just has that much better memory management/stability.
Because Chromium runs far better in my experience, especially on Linux, and especially where graphics and WebGL are concerned. If all I can use are WebExtensions, I may as well use Chromium for the speed.
You really should use Firefox if you are a heavy WebGL user, Firefox is 3 times as fast as Chrome now on Unity3D, an it's the complete opposite, Chrome is more snappy with Java and Firefox with animations/Graphics.
In my experience on Linux, the difference is night and day, and not in Firefox's favor. Really basic demos struggle to get 30fps while Chromium handles them at the refresh rate of my display no problem.
Firefox WebGL works much better on Windows for me; never tried it on OS X. It's probably a Linux-specific issue, but I rarely use Firefox on anything else.
Linux is another beast, on my Ubuntu box Firefox gives similar performance to OSX. But on my Debian stable box Chromium plays a lot better with it and the Firefox build feels like it has a gremlin in it haha.
Also if you want to get to the root of the problem, when you install Firefox 51.0.1 in the URL bar type "about:support"
It will list HW acceleration info. You want to make sure electrolysis is running, in the line "Multiprocess Windows: 1/1 (Enabled by user)" should be enabled by default, if it says 0/1 it not active and you will have to manually turn it on.
You can also see if the WebGL renderer is loading properly. On my Debian box it says WebGL2 creation failed (drivers), which would explain my poor performance on that box.
It's worth a shot since Firefox's WebGL rendering is 4x faster then other browsers, it's worth your time taking a quick check.
I switched to Chrome a year ago and while it was a little rough at the start I am very happy overall now. Shame but Firefox was just so much slower that it was annoying me. Plus Chrome syncs everything much better than Firefox ever did.
Firefox also seems slightly faster for me than Chrome (and Safari feels _a lot_ faster), but that's not enough to switch, since I'm so used to Chrome's sane UX and sync (and with a passphrase I'm pretty comfortable having that on Google's servers).
Only about 250,000 users use the tab modification extensions that people keep claiming is Firefox's only advantage out of 10s of millions of Firefox users. Addons that greatly alter Firefox's behavior are the main reason for crashes. And maintaining XUL is hampering Firefox future development.
I forgot about TMP. Even so, that's still not a ton of users in terms of the total Firefox users. Plus, I'd wager a large percentage of those are TMP legacy users. Way back in the day, TMP was the only way to properly manage sessions and tabs. Firefox now has full session management and you can reload, pin, undo close, close other tabs, and move tabs around to your heart's content. Heck, the most recent review of the extension even says as much.
But tabs-on-the-side is important enough that they are running an experiment with a first-party extension right now. https://testpilot.firefox.com/experiments/tab-center It's gong to be a priority for the new extension model to support this kind of thing before FF57.
https://blog.mozilla.org/press/ataglance/ says it's near 500,000,000. But while Firefox tries to keep the core browser lean, they have always catered to power users through the extension APIs.
Rikaichan allows translation of Japanese words simply by hovering your mouse over. It works much better than entering words into an online dictionary, since nearly every free JE-EJ dictionary uses the same source, and if a conjugation isn't translatable it will cut the word off giving the meaning and then letting you easily highlight the conjugation to figure out the meaning of the two together. Its just much faster than using something like jisho.org if theres a lot of words in a text you don't know. Rikaisama makes Rikaichan even more powerful with a lot of extra features
Everytime I've ever tried the similar plug-ins on Chrome they've all been terrible, missing words, missing conjugation, or just being slow in general. Its the first check I do every time I think about switching browsers.
However with the new Electrolysis on Firefox its completely broken and it seems like the dev might not want to do a rewrite since the plugin works exactly how you would want it and has for a few years now, but especially not if the sandbox changes make the plugin impossible to work.
I've been using Rikai-kun[1] on Chrome. It claims to be a port of Rikai-chan, I'm curious in which ways it's inferior (I have not tried the original Firefox addon).
Same here. Is the Lookupbar (Alt+Del) possible to do with WebExtensions? I think it would have to be recreated in the DOM and inserted into the web page.
There's nothing difficult or complex (or unsupported) about inserting content into web pages. The main limitation of webextensions is that free-form UI modification is no longer possible, the UI can only be modded in specific, allowed ways.
No, but there are several reasons it is suboptimal here.
The lookupbar is associated with the window chrome (ie. there is one per window). Inserting it into the DOM requires emulating this behavior by synthesizing one "bar" in each tab, adding and deleting them at the right time, etc.
Inserted content always has the possibility of interacting poorly with the scripts and styles of the underlying page (or other extensions). Rikai-chan already has problems where its overlays will end of underneath page content.
For Rikai-chan, it seems like it'd be nice to allow the background script to write to a page that sits on top of the space that shows the actual page and have the content scripts communicate what should be rendered. AFAIK, the only ways to show something on the screen is to either send it to the content scripts and have them modify the DOMs, or show it in a popup for a button.
That might be nice for the occasional translation, but it pales in comparison to the usability and experience Rikai-chan offers or I guess soon offered.
Still waiting for a lightweight browser that works on Windows (Linux has bad battery life even after very very aggressive power optimization) and doesn't use 4gb RAM and 89% of my battery. If anyone can do that then I'll switch.
No. However, I am the developer of "Download Cleaner", which is made using Add-on SDK. I think it's a great solution to get started without learning XUL.
I'm sure they had their reasons for deciding what they did. I still think it's a bad decision.
The next Firefox ESR will be based on Firefox 52 (to be released in March). Firefox 52 ESR will continue to support all add-ons and receive security fixes until sometime in 2018 H1.
About 2) : the multi-process model is not "1 process per tab", but "M tabs sharing N processes". So you won't end up with 40 processes in your case. I've been running nightly with 5 processes for months and found that to be a good setup.
Vimperator has an issue in it's github referring to e10s and webextensions from 2015. It was commented upon a few times through 2015, more in 2016, and obviously more now. Nobody ever started moving forward. Only 10 days ago, a different issue was opened with regards to porting to an entirely new codebase for vimperator that uses WebExtension. They just now are talking about getting in touch with Mozilla for API requests.
Mind you, a year plus ago, multiple mozilla developers were holding office hours blocked out in the day to explicitly talk to e10s and webextension developers. It got scaled back because nobody ever talked to them and paid developers cannot be paid to do nothing for hours at a time when nobody calls in/emails/etc.
Meanwhile OTHER plugins HAVE taken this seriously, but not a lot of them. Certainly not enough. And yes, that means that you are going to have those plugins lose compatibility. But that's not firefox's fault. Mozilla has done everything they can do to help this transition, including paying people to help, pushing it back multiple times, giving numerous conferences, opening up api requests, and communicating on most every forum available on the internet.
It's on the plugin developers now. That's where your anger should be. Not on the company that is doing, finally, what it said it'd do numerous years ago.
My recollection is that both are as bad as each other: spiteful UI with 1 watch window and a fixed window layout. Dear people - start demanding more from your tools.
Going back on topic, I've stuck with Firefox for years because of DownThemAll and Firefox Sync. But I stopped using sync a couple of years ago, so that just left DownThemAll... which won't work after this change. So I'll probably leave Firefox behind. Safari supopsedly gives you better battery life on OS X, and Chrome is more popular (i.e., people probably test their stuff on it).
Almost every day I use both of them. They both have pros and cons. It's all about having practice and spending time on any of them. But one thing for sure is a game changer that is FF dev tools can show you the events bound on element right next to it, unlike chrome's list of events.
I am honestly starting to believe that Mozilla is trying to run Firefox into the ground. I am not sure if it's just bad decision making or if the decision makers themselves had been bought off by competition, but it sure does feel like this. Why do we need one more Chrome like browser out there? I specifically use Firefox because it's a) not chrome, b) has better addons. If you hamstring the addons and make everything chrome/chromium like, what's the reasons to use FF then?
The add-ons might be better, but XUL-based Firefox add-ons are not better. They essentially give full control of your computer to the developer of the add-on. There's no permission model. The "APIs" are mostly the internals of Firefox itself, and when Firefox updates, lots of add-ons break.
Most add-ons can be ported to webextensions. The ones that can't probably shouldn't have ever been add-ons to begin with.
Lots of other browsers used to do the same thing Firefox does, and chose to use a webextension-like model instead. Why? Because those screenshots of folks with half their screen consumed by toolbars, weird popups, overlays in the browser viewport, extensions that sneakily inject ads into pages, and track user behavior _still exist_. And there's really nothing Mozilla can do to stop them.
Do you know how Firefox add-ons get approved? A human sits down and sifts through the obfuscated source code. I helped build these tools years ago, I can tell you it's hell. Beyond being error-prone, it causes months-long delays in add-ons getting approved.
Firefox will be better off for only supporting webextensions.
Lots of other browsers used to do the same thing Firefox does, and chose to use a webextension-like model instead.
Really? Name three.
Your arguments may be true, yet they fail to answer the question: "If you hamstring the addons and make everything chrome/chromium like, what's the reasons to use FF then?" If Chrome made all the right decisions, we might as well kill off the Firefox project.
Your comment assumes that add-ons are the only reason anyone would ever use Firefox. Personally, I don't use many add-ons, and if Firefox is faster or more battery optimised than Chrome, I'll use it.
Internet Explorer followed the same path. Edge is more restrictive for the same reasons which the Mozilla developers have discussed at length: security and reliability suffered and users inevitably blame the browser for the results.
> Firefox will be better off for only supporting webextensions.
Sounds like Firefox developers will be better off. Everyone else will suffer.
I'm a developer, I understand how much the job sucks sometimes (that's why it's a job). But if you want a product to succeed, can't afford to put the comfort of your developers over that of the end user.
No, security threats make both developers and users worse off.
It's undoubtedly true that power users will lose a little of the functionality they like in Firefox, but that normal users will have a more secure browser. I'm sure someone will fork Firefox to keep a version alive for those power users.
You might not agree with it, but the logic is sound.
So, fix the problem instead of throwing the baby out with the bathwater.
I get it, it's a hard problem to fix. There would be a lot of pain in getting there, both for Mozilla and addon developers. But throwing in the towel feels like a cop-out.
The logic is sound, but so is closing down every theater because someone got shot in one of them. After all, everyone has TVs and blu-ray players now, and you can't get shot in a theater if there are no theaters...
But this is the fix. Instead of allowing open access to the internals of Firefox, which will never be secure, you use a limited API. It isn't difficult to imagine that they can expand this API later to allow things that aren't currently possible. It's a hard problem to fix and there will be pain getting there.
And the theatre analogy is just silly. It's not like shutting down a theatre because someone got shot in it, it's like enacting a "no guns in this theatre" policy instead.
This is a fix. It's not the only fix. I postulate that it's probably not even the best fix for Firefox.
> Instead of allowing open access to the internals of Firefox, which will never be secure
Android, iOS, and many other OSes do this all the time via rather granular ACLs. It can be done.
All analogies are flawed - but Firefox is closing the theaters by completely killing off their add-on interface in exchange for an comparatively shallow experience.
> Android, iOS, and many other OSes do this all the time via rather granular ACLs.
If it were that simple, then the Chrome team would simply have asked the Android team to provide their expertise in designing Chrome's extension API. And of course, it's not like Android provides apps unrestricted access to the hardware (there's a reason that people bother to root their phones). Firefox addons are currently less restricted than Android apps.
> the Chrome team would simply have asked the Android team to provide their expertise in designing Chrome's extension API
Chrome's choice to not use such ACLs has no bearing on whether it is possible or reasonable for a web browser to use. Chrome is not the be-all-end-all of browser technology.
> Firefox addons are currently less restricted than Android apps.
And that's what could be changed. The lack of restrictions in the current state doesn't mean that it can't (or that it shouldn't) change.
> It's undoubtedly true that power users will lose a little of the functionality they like in Firefox, but that normal users will have a more secure browser
Why are these 'normal users' going to use Firefox when their power user friend no longer recommend it, when Google is pushing Chrome as hard as they can on every Google property, and when there are even installers that 'offer' to install Chrome for you? Mozilla can't compete with Google and Microsoft marketing efforts, they can't make anything more than a UI for the most popular mobile browsing platform, and they're alienating power users. Who is going to be pushing Firefox to normal users?
They may be easier to write but they aren't as powerful. There are a number of examples of addons in sibling comments which won't exist any more because Mozilla wanted to make it "easier".
Even PG has remarked in an essay that success isn't easy - the people who will really succeed are the ones who put in the effort to do the hard things.
Er, designing an honest-to-god specified extensions API is harder than just telling addons developers to run wild with your undocumented and unstable browser internals. Appealing to PG makes no sense here.
> designing an honest-to-god specified extensions API is harder
Of course it's hard. Doesn't mean it shouldn't be done.
> Appealing to PG makes no sense here.
When the argument is being made that it's better to make it easier on Firefox developers at the cost of the user base, the argument made in PG's essay is pretty relevant.
> Of course it's hard. Doesn't mean it shouldn't be done.
What? kibwen is saying that that is exactly what Firefox is doing!
Bear in mind that this is not just "copying Chrome's API", it's copying the base design (how the manifest works, etc), and adding new Firefox-specific APIs on top of it. The whole idea is that most of the APIs addons need will be added to firefox's webextensions API.
> weird popups, overlays in the browser viewport, extensions that sneakily inject ads into pages, and track user behavior _still exist_
all of this is possible to do with webextensions, just add a contentscript for all_urls. Of course webextensions help with some security issues, but not with the ones you mention.
But I want the addons to have full control over my browser, that's the whole point! It's my browser and I've tailored it to myself and my requirements.
The one thing that is striking every time I try to use chrome/chromium is just how limited the addon functionality is and how much less freedom the user has. Have you seen "treestyletabs" implementation on chrome? It's a whole other window that has to be started and placed side-by-side with the browser window by user because of the addon limitations. There are also some keybindings which are fixed forever and not allowed to be changed (<C-W>, <C-N> etc).
Of course you can justify the restrictions by bringing up the case of the poor average user who will get abused by his browser having more functionality that he will ever need. But the thing is - I really don't care for the "average user" and its problems. Average user is a beast that is perfectly happy to be contained in the walled garden, but we already have Chrome and Android for that.
While i agree with the idea of being able to install whatever you want. What's wrong with it being behind a developer mode?
I would bet that 99%~ people don't need or even want that kind of absolute freedom. As a chrome user, the only plugin I have that I can't get on the play store is one for downloading youtube videos but I can still install it from the author website, just takes a few extra clicks.
> What's wrong with it being behind a developer mode?
The fact that one doesn't exist. "Developer edition" is really just their alpha build, they don't have release builds that allow unsigned extension installs.
But Mozilla cares about average users, not about making something for power-users only. That seems to be the big conflict here: power users saying "you've lost the masses, so make something for us" while Mozilla's mission is making something that would be good for the masses, and they'd rather fail trying than failing that mission by abandoning it.
The set of clueless users who would install arbitrary malicious extensions and the set of clueless users who would download and run arbitrary executables is basically the same. Yet if they do the latter, any extention sandboxing is completely and utterly moot. It's the same issue as with mandatory extension signing; requiring signing for extensions while nothing stops someone from downloading an unsigned .exe (which could memory-patch Firefox if it so wished) is absurd.
The power users are saying, Firefox became successful by being powerful. When it ceases to be powerful, it will cease to be successful. People will just use Chrome.
But when they roll out their Servo Renderer late this year everyone will be singing a different tune. Firefox is already faster then Chrome with the Electrolysis update, but Servo is rendering completely on the GPU. I just tested the the dev build of Servo and it's so fast it almost kicked my dick off!
Servo has been in Dev for 5 years, so if google isn't working on something to compete with that, Firefox is going to completely dominate the web for years.
The only reason Firefox became popular in the first place is because it was adopted by power users, who then evangelized it to their less technical friends and family.
When Firefox is no longer an attractive option for power users, the only thing it will have going for it is ideology. And that will not be enough to compete.
> I want the addons to have full control over my browser
I can assure you that you only want this if you can guarantee that your add-ons only do what they claim, don't have security vulnerabilities, and are never acquired and maliciously updated. Otherwise, a permissionless add-on model means a bug in TreeStyleTabs could potentially be used to exfiltrate your entire password database, plant malicious binaries on your system, and destroy local data. If TST had limited permissions along the lines of only being able to manipulate tabs and their UI, that wouldn't be a problem.
> Have you seen "treestyletabs" implementation on chrome? It's a whole other window that has to be started an placed on the left of the screen by user because of the addon limitations.
Is that a statement about future Firefox visions or Firefox 57? I assume you know the gritty details while I'm a rather confused Firefox power user / fan / advocate (using .. addons that are affected, vertical tabs/tree style tabs plus vimperator/pentadactyl mostly).
The outrage The Internet™ seems to feel is probably not about XUL being deprecated/killed. I'd say no user cares about the technology, the only people even caring are probably the addon developers.
From what I can tell, the outrage is mostly due to the impression (and I dearly hope that you will dismiss this as wrong, just like the 'addon limitation' reference above) that the web extension switch happens before popular, polarizing addons are even remotely possible given the new API.
"Will not have this limitation", as in "it won't support that use case in 57 at all" or as in "you can do better than this Chrome extension you describe"?
You're basically correct about the APIs, though. Developers of some popular add-ons don't know when or if the APIs they need will be implemented. Support for migrating gradually (embedded WebExtensions) was just released in 51 and will be gone in 57 -- not even a full ESR cycle.
Developer burnout is a problem, too. This comes right after many of them put in significant work making their now-deprecated code multiprocess-compatible, which came after mandatory extension signing, which came after a bunch of UI changes. It's not surprising some of them have quit.
Pseudalopex pretty much nailed it; Google has strongly resisted adding sidebar APIs to Chrome, or allowing add-ons to hide / relocate the tab bar. Those are two of the major reasons why it's difficult to build a quality Tree Style Tabs add-on for Chrome. Firefox will explicitly include APIs that allow that, which should be landing soon.
Most of these changes and their timelines are motivated by fundamental architectural work happening deep down in Firefox. We're doing the best we can to get as many add-on APIs in place before 57, but for heavy add-on users, it has the potential to be a rough transition.
For deeper meddling in the browser, and for APIs that don't yet exist, WebExtension Experiments (https://webextensions-experiments.readthedocs.io/en/latest/i...) should provide a reasonable option. Basically, you can keep using old-style "bootstrapped" add-ons in DevEdition and Nightly. Kind of an explicit way to opt-out of API stability guarantess so we can continue refactoring the browser core. Experiments are intended for prototyping new WebExtension APIs for eventual inclusion into mainline Firefox, but you could also use them for power-user APIs, so long as you don't mind the maintenance burden.
A sidebar API and tab modification API will be implemented specifically to allow TST to work. The addon will have to be rewritten completely on a very short timescale, though.
So, can I use that to add Tab Thumbnails to Firefox? Can I use it to port AutoHiDPI, which changes the scale of the UI depending on which screen the window is on?
Can I use this to replace the entire browser history system and omnibar autocomplete with a custom one?
Can I use this to replace the entire browser chrome?
Some of these changes I need (AutoHiDPI) to use a browser at all. Others I wish for. All of them I currently am using.
The alternative is me staying on an ancient browser, or forking Firefox and browsing with a horribly outdated and barely patched version. Or reading HN with a magnifying glass.
Replacing the entire browser chrome is unlikely to happen on the release channel of Firefox, but everything else has potential.
Generally, the way forward will be to use WebExtension Experiments (https://webextensions-experiments.readthedocs.io/en/latest/i...), which let you run classic-style "bootstrapped" add-ons in Firefox Developer Edition or Nightly. The intended use is for prototyping new WebExtension APIs for eventual inclusion into mainline Firefox, but nothing limits you to that usage.
That’d require a lot of work from me – at this point it would be easier for me just to switch to Vivaldi, or hardcode my fixes as patches into Firefox itself.
In fact, the per-screen HiDPI setting even has an environment variable on most Linux systems (Qt’s QT_SCALE_FACTORS), but Firefox completely ignores that.
I don’t have the time anymore to rewrite half the UI stack of every single application I use, and then take over maintenance of that. I’ve done that with a few open source projects, but my time is limited. And if I wanted to implement extending the UI properly, I’d definitely have to rewrite the entire stack, similar to what Browser.html does.
Well Palemoon is a fork of pre-Australis Firefox that is trying to maintain compatibility with the existing XUL extensions as best i can tell, so i figured the transition would be smaller than going to a webkit/chrome based browser.
> But I want the addons to have full control over my browser, that's the whole point! It's my browser and I've tailored it to myself and my requirements.
Owning the code that runs on your machine is your right as a user of open-source software, but there's no right that says that Mozilla must be the one to maintain that code. And nobody's asking you to maintain your own personal fork either: find all the other people who care about unlimited (if fragile) browser extensibility via unrestricted addons and form a community (or hell, a corporation) to collectively make the browser you want, starting from a fork of Firefox (or Chromium, or Midori).
If you believe that there are enough people in your position to make such a collaboration successful, then you're all set. And if you don't believe that there are enough people out there who care about unrestricted addons to make such a project viable, then--while I sympathize with your plight--maybe it makes business sense for Mozilla to drop support for unrestricted addons, especially due to the ways that this feature hinders all the other features that Firefox users are clamoring for: speed, reduced memory usage, speed, HTML5 adoption, speed, ES6+ adoption, speed, speed, security, and speed.
From where I stand, it looks like they're trading one of their big advantages for a massively reduced maintenance burden which will unquestionably allow them to compete better on every other front. It may or may not pan out, but I think we can all agree that some change of trajectory from the past few years is needed if Firefox hopes to stay relevant. You're free to think that Mozilla leadership is incompetent, but in this particular instance I think their stance is grounded in sound reasoning, as inconvenient as it is undoubtedly is for some power users.
> You're free to think that Mozilla leadership is incompetent
Source on me saying that? I think they are making a few dumb decisions, but that's putting a lot of words in my mouth.
FF has very few advantages. They aren't competing on speed, mind-share, ease-of-use and now they aren't competing on reliability of add-ons. I get that this can help them focus, but pushing away their limited user-base is like using an axe to help a sinking ship.
>The add-ons might be better, but XUL-based Firefox add-ons are not better.
This statement is contradictory.
>They essentially give full control of your computer to the developer of the add-on. There's no permission model.
Yes. I know. That's why it's better.
>Most add-ons can be ported to webextensions. The ones that can't probably shouldn't have ever been add-ons to begin with.
You're pushing a worldview here in which some entity - Mozilla, presumably - sees fit to decide in what way I should, or should not be able to extend my web browser. I reject this premise.
The whole point of XUL/XPCOM, as you yourself seem to realise, is that it naturally exposes browser internals and thereby enables permissionless innovation. The only reason WebExtensions can even support the use cases it can is because Mozilla basically looked at the popular addons and defined it to be able to support corresponding functionality. Extension developers finding gaps in WebExtensions APIs were invited to communicate this to Mozilla - that is, to ask Mozilla for permission to extend the browser in a certain way (and for them to allocate manpower to adding that API, etc.)
The idea is to make WebExtensions politically palatable by happening to support what's popular, but that very approach proves the impracticality of the premise. If ad blockers were invented tomorrow, would there be a WebExtensions API? Probably not. Would Mozilla bother to allocate manpower to adding an API for it when one person has the idea and asks? Probably not. If Firefox (and before that, Mozilla Suite, etc.) had had only WebExtensions-like APIs from day one, would ad blockers exist today? Probably not. Ergo, we can conclude that future, yet unconceived innovations will be prevented by this change. The "ask us to add an API for it" approach is not acceptable, given that the technology to make this a non-issue (XUL/XPCOM) already exists and is in use.
>Lots of other browsers used to do the same thing Firefox does, and chose to use a webextension-like model instead. Why? Because those screenshots of folks with half their screen consumed by toolbars, weird popups, overlays in the browser viewport, extensions that sneakily inject ads into pages, and track user behavior _still exist_. And there's really nothing Mozilla can do to stop them.
This isn't Mozilla's problem, and as you yourself acknowledge, trying to save users from themselves is a futile effort.
>Do you know how Firefox add-ons get approved? A human sits down and sifts through the obfuscated source code. I helped build these tools years ago, I can tell you it's hell. Beyond being error-prone, it causes months-long delays in add-ons getting approved.
If this upsets Mozilla, they could get out of the extension approval business. Nothing obliges them to intermediate themselves in this way.
No version of Firefox which implements restrictive code signing practices will ever touch any system I control. Currently I use Firefox Developer Edition. It doesn't appear it will be updated after version 56.
> They essentially give full control of your computer to the developer of the add-on.
That's the entire point. Firebug could not have existed as a WebExtension, and thus without XUL addons the entire web development field could still be on Venkman or Script Editor rather than where it is now.
The XUL extensions model allows extensions in ways unmatched by WE, and yes the development experience isn't tremendous and it's a serious security risk, but that means it's possible to experiment or customise in ways WE don't allow. Users could get things like NoScript and greasemonkey and ad blockers and tree-style tabs without having to demonstrate its value to the browser developer and needing to get the tool itself or some necessary API integrated and merged into the browser.
> Most add-ons can be ported to webextensions. The ones that can't probably shouldn't have ever been add-ons to begin with.
Exactly. Now they killed Firebug. And their newer DevTool has a Firebug skin - just a skin. Very bad devision. So now I reverted back to an older Firebug version, which is actually the true Firebug addon.
This means I will now have a zoo of old outdated browsers. Safari 5.1 Win32, Firefox 56 Win32 with Firebug addon, IE11 on Win7 (plus Chrome, Vivaldi and Servo alpha)
I have hope in a lightweight reboot of Firefox based on Servo with HTML based UI (like Firefox was a lightweight reboot of Mozilla Suite; funny that Firefox is now many times more bloated than Mozilla Suite (now called SeaMonkey https://en.wikipedia.org/wiki/SeaMonkey ) and has less features)
The question "Why would you use Firebug considering both Firefox Dev Tools and Chome Dev Tools have more features and don't cause the entire browser to horribly lag?" remains.
I use all three tools. But Firebug still has features that aren't implemented in both other tools. You can read the Bugzilla entries, sadly Mozilla cut off Firebug too early, many minor features (eg DOM tab) were just recently added to Firefox DevTools and aren't working 100% because of glitches and bugs. And Chrome DevTools don't has those features at all.
(I use a separate Firefox instance for development, and it's not my number one browser for years because it can't handle hundreds of open tabs - IE and Chrome excel on that (my) requirement for 10 years.)
For real. I understand the security argument, but that poster and Mozilla in general seem to be making the argument that "no, you're wrong, you don't know what you want, we're going to tell you what you want, and it's a less feature-rich Firefox."
Well, I use Firefox, and I evangelize Firefox to everyone I know, on the basis, essentially of the extensions, and most of the popular Firefox extensions would have never come into existence with the new extension model. Mozilla is developing APIs to grandfather some of them in, but they're still reducing the possibility space from "anything" to "what we expose through these APIs", so new extensions that change everything will no longer come into being.
And aside from that, they don't even cover everything; I've already been notified by the developers of two extensions I use that they either can't or won't be switching over.
I really do have to agree with the people who are saying Mozilla has totally lost the plot. I've disabled automatic updates until I can figure out what I'm going to do.
>XUL-based Firefox add-ons are not better. They essentially give full control of your computer to the developer of the add-on
XUL does open up more attack surface than a web extension. However, web extensions open up enough that you're already in the business of trusting the creator of the extension.
A web extension is fully capable of stealing my online banking credentials, for example.
Web extensions are vetted by amo reviewers if they come from that channel. Is it going to catch every single malicious extension? Doubtful. Is it better than nothing? Yes.
I suppose. The whole idea just seems to miss that for many, online data is more important than my local pc. A web extension that deleted my google account would be more disruptive than an XUL extension that formatted my hard drive. XUL is a superset, but restricting to "web only" leaves you with the most significant subset...at least for me.
> Web extensions are vetted by amo reviewers [...]
But so is every other type of add-on. You even need to upload source code for binary components. (A XUL extension can include DLLs or their cross-platform equivalents.)
> you're already in the business of trusting the creator of the extension
Those were my thoughts exactly.
And tangentially related to your point, I am wondering why the addon developer, who I have explicitly trusted by intentionally installing their software, is not at least on the same or even higher level of trust as an unknown 3rd party web developer whose arbitrary Javascript application the browser automatically installs and runs when I visit a desired 1st party website?
There are no built-in protections that Firefox (or any browser) provides for running arbitrary 3rd party code that happened to be included by an unsuspected website that features 3rd party fingerprinting, tracking user actions, access to DOM, whether for "benign" or malicious purposes. In my mind that is just as, if not more, important for both security and privacy.
It looks like it is yet to be seen whether Mozilla's extended WebExtensions API will provide enough for existing add-ons that use current low-level access that to some level restrict 3rd party web applications.
> The add-ons might be better, but XUL-based Firefox add-ons are not better. They essentially give full control of your computer to the developer of the add-on.
IOW, the addons are software, just like Firefox is. That is what makes them useful.
> Most add-ons can be ported to webextensions. The ones that can't probably shouldn't have ever been add-ons to begin with.
I hope you realize that this attitude is 100% the opposite of the original Mozilla team, and that Firefox and Mozilla would not exist today if it had been. Firefox became what it is today because of its customizability and its empowerment of users.
> Firefox will be better off for only supporting webextensions.
On the contrary, it will no longer be Firefox.That is the point that we 15-plus-year, loyal users have been trying to drive through the thick heads at Mozilla.
If I wanted to use a browser like Chrome, I would use Chrome. What kind of product manager thinks he can beat his competitor by essentially duplicating their product, when there is no differentiation on price? Both browsers are free. People are already using Chrome because Google has what is essentially a Microsoft, IE-style de facto monopoly. People can still use Firefox if they prefer it--but if it ceases to be unique, why would they bother?
Firefox 56 will be the last version of Firefox I use, because Firefox 57 will no longer be useful to me. That is the bottom line.
For now using Firefox ESR might be a good stopgap measure for you?
That way you can use an old version with the old add-on ecosystem for at least a year longer, and still get security updates.
I usually work on Debian Jessie which ships (a variant of) Firefox ESR, and it's very well-usable. I haven't noticed any differences between the latest Firefox on Windows and Firefox-ESR on Debian.
The latest LastPass, XMarks, VimFX, uBlock Origin and uMatrix run on it, though I haven't managed to get RES (Reddit Enhancement Suite) to work.
The situation with Vimperator is so sad, I can't use Firefox without it.
I don't like all those toolbars that clutter my screen estate, I prefer to browse the web full screen. There are a lot of projects using Webkit, and I also use elinks a lot, but I'd rather support Mozilla and Firefox by using the later when I need a graphical browser.
Badly performing addons are the main reason behind Firefox crashes. The majority of users don't use addons. Of those who use addons, the vast majority use just one: an ad blocker. Those addons work fine under new Firefox.
There are lots of reasons to use Firefox over Chrome. It's not designed to drive traffic to a search engine. It has far better privacy out of the box. It's a standalone browser that isn't tied to the operating system for things like personal certificates. It doesn't lock its settings to the operating system so you lose all your passwords, extensions, and extension settings if you move it from one PC to another like Chrome does. Etc.
Ouch, the comments over there are extremely negative. As mozilla is our last bastion of hope between advertising giants it pains me to see mozilla having an increasingly hard time to sustain a positive brand image.
It is crazy if you think about it, because Mozilla is the last giant that respects its users. It has a very good proposition with regards to privacy and user-interest alignment.
There are still tons of less-then-smartª people using Chrome. I blame Mozilla for not doing any smart marketing at all.
____
ª Its fair to call it that way. You use a browser more than a car. Yet people do research before buying a car and carefully weigh the downsides versus the upsides. But not for their most important software application in their lifes.
You are right. I did and do not say every chrome user is stupid, there might be legitimate use-cases. But the vast amount of people just install chrome or get it side-loaded with some freeware and don't even think about their options and the impact of their choice. Now that is less than smart.
FWIW, though I'm an avid supporter of Firefox and use it, my very consistent observation is that security experts believe,
* Chrome/Chromium is more secure against attacks by governments or criminals (i.e., attacks against the integrity of the system; I can't think of the right word).
* Firefox may be more secure against advertising and corporate confidentiality attacks.
* Firefox with certain add-ons, too technical for most users, may be as secure as Chrome/Chromium.
The fundamental difference is that Google is a gigantic engineering organization that dedicates enormous resources to security, benefiting Chrome directly and indirectly. Over the years, lots of work has been done to ensure and improve its security at a design and architectural level.
Firefox, as this announcement shows, is just getting around to freeing itself from design decisions which may have made sense over a decade ago when Mozilla had 'software suite' ambitions but we now know are a liability for something with the security demands of a browser.
> design decisions which may have made sense over a decade ago when Mozilla had 'software suite' ambitions
It doesn't change your overall point, but I think this part is incorrect. AFAIK abandoning those ambitions was the reason they left Seamonkey behind and developed Firefox.
Firefox started well before Seamonkey was spun out, and they continued with Thunderbird anyway. But the details of the history of the ambitions don't matter, what matters is that these architectural decisions were made a long, long time ago but their consequences are still there. You can decide you're not going make an app suite, that doesn't magically re-architect the internals of the product you have. Take a look at this announcement from Netscape, in 2000 (AD):
> You can decide you're not going make an app suite, that doesn't magically re-architect the internals of the product you have.
I'm not sure how that applies. Firefox wasn't magic; Mozilla rewrote their browser intentionally and put a lot of resources into it.
> Firefox started well before Seamonkey was spun out
My understanding of that statement is that they didn't drop the old product until the new one was succeeding in the marketplace. I'm not sure how that impacts what I said.
Firefox wasn't magic; Mozilla rewrote their browser intentionally and put a lot of resources into it.
No no, they didn't. Firefox and Mozilla (and even later versions of Netscape) share the same architectural underpinnings. That's sort of the intent and cleverness of it, it's really an entire system for writing cross-platform apps, with its own 'language independent' component model, gui layer, etc. The things that made Firefox possible also made all-powerful Firefox extensions possible. Much of that architecture is still around. In the intervening years, it's become obvious this is not necessarily a good way to build a browser. Which is why they are dropping XUL/XPCOM extensions. If they'd 'rewritten' it, they wouldn't need to do that.
My understanding of that statement is that they didn't drop the old product until the new one was succeeding in the marketplace.
I'm talking about common architecture, not products. If you're unfamiliar with it, just scroll through this
Just compare the amount of code execution CVEs found on a yearly basis and the level of severity of each. Then think of how Firefox has much less marketshare than Chrome (FF sits around 8% and its share keeps going down year by year), so Chrome should be a more interesting target for hacking.
Then come back and tell us which browser has the lesser amount, and when some are found, which is most likely to have the more severely exploitable vuln.
> It's the most secure browser available. That's a not a 'might be legitimate' use case.
It may be Jesus on a popsicle, but I'm not going to trust something distributed via drive-by-installers, marketed through SPAM and made by the world's biggest data-hoarder and privacy-invader no matter what.
It's adware/malware short and simple.
Make it 100% FOSS. Remove any technical connection to Google. Don't require Google-logon to sync. Only distribute it to users who actually asked to have it installed. Etc etc.
At that point I might consider starting trusting it. Not before.
No, not at all but by the vehemence of your reply, you make it sound like Chrome or Chromium force you to give these things to google. And I don't think they do.
Go look at the CVE reports for each browser. Your taking a > 10x risk running anything other than Chrome. These changes Mozilla is making are to fix that.
The answer to "This piece of software has a track record of being more secure than this one, due to its design, and these changes in part help fix that disparity" IS NOT "I'm going to use a calculator now because nothing can be secure so what's the point anyway stop trying to force me to eat my dinner vegetables i'm not listening".
I don't even know why this needs to be said, because it's fairly obvious nobody on Earth actually does risk analysis this way. I mean, unless you're a programmer with some sort of brain worm infestation, who cannot read between the lines, and have an inability to understand how people in the real world do (and must) operate, clearly.
From your other posts you seem like a reasonable person, so I'll try to explain myself better despite the verbal abuse.
I realize that some software is more secure than others, and that changes can be made to make it more secure. My point is that you can't simply say "therefore these changes are necessarily good", because there is more to software than security, and those changes often involve tradeoffs in other areas, which have to be weighted. For some of us, in this case, those tradeoffs aren't worth it.
Making up numbers doesn't help the discussion. Can you prove that firefox users are at all more likely to be infected in practice? I doubt it. You surely can't prove they are 10x.
Chrome comes with Flash, and Flash vulnerabilities are not counted against Chrome. So this is highly skewed. (Never mind CVE counts being a poor proxy of risk)
I agree generally with your points, but this doesn't really address the issues being criticised in comments here. I want to use Firefox (I do currently use Firefox, despite a lot of limitations), but there comes a tipping point where the balance of privacy (and apparent "user-interest") and actual usability and power leads to a not-so-good proposition.
Someone has commented above that it seems like Mozilla management may have been bought off by competitors and may be deliberately trying to run Firefox into the ground. I don't believe this, but given the recent decision-making it's not entirely implausible.
Opera went a similar path ~5 years ago. Most Mozillans don't consider this comparable as Opera was closed-source (and there's this one-track tunnel vision people have around that term), but the similarities are stark. A company with a history of listening to its users and a massive level of contribution to open standards and interoperability, making a product that served a niche userbase extremely well, decided that aping it's mainstream competitor (Chrome) directly would somehow be a good move. Now there's no discernible difference between Opera and Chrome, and no reason whatsoever to choose the former over the latter.
I can't rule that out either. It might be that it is in Googles best interest to kill firefox.
Here is an alternative view I have in mind. The strategy to mimick chrome makes sense, because the masses think this is how the browser -- or as they call it the "internet" -- should look like. Its imho feasible to launch a television and internet campaign promoting firefox after the transition by stressing the privacy qualities. Mozilla has a quality other venders don't have.
By making it a pain free switch a big market share is possible for firefox.
Still, i doubt the current board has this view really in mind. I am thinking if I should apply for a position :)
> The strategy to mimick chrome makes sense, because the masses think this is how the browser -- or as they call it the "internet" -- should look like.
But that's what FF has been doing for the past ~5 years, and how has their share been doing? Not so well.
Chrome has much more marketing behind it. And it comes from a name that people know and trust. Most people don't know who Mozilla is. And most people don't care about avoiding Google. So if I have two browsers, and the lesser known one is constantly following the other, why would I choose it? I'd rather take the leading browser. It seems as if the FF one is just playing catchup the whole time.
I love Mozilla and FF because it respects me. But it often feels like they are losing that respect just to play follow the leader
> And most people don't care about avoiding Google.
...if that changes, everything changes. Thats the same thing with Signal and WhatsApp. I am positively surprised how easy it is to convert people to Signal and the momentum they are gaining.
Maybe they are betting on the very long term? Tbh, I would expect a more focused marketing from Mozilla if that would be the case. I am almost as much confused as you are.
That's a big "if". How likely is it to change? If history shows anything, not very. Don't get me wrong, I strongly hope they can knock Google off the top spot. But hope doesn't ship units.
Is it still true you can't do extensions for Chrome on Android? If so, they should just do a commercial showing you can use uBlock Origin with it. That could get a good chunk to move on Android and if they use it there they might switch on desktop too.
Definitely. This is exactly the reason I switched from Chrome ro Firefox. I mean, when I'm on mobile it's even more important than on desktop that I have my adblocker in place, as both bandwidth and screen estate are more limited.
I'm not talking about showing off extension support, just ad blocking. I hate extensions myself, I wish content blocking with white listing was just built right into the browser which is that last real feature any browser needs. Once people get a few weeks with a good ad blocker they won't ever go back. After that, if they use a browser without it, they'll think they have a virus.
Chrome is an adware that is distributed by Google. It is bundled with most of Google products and a huge amount of software setup, because Google pays publishers some pennies for every new installation.
I have seen a lot of people who have had Chrome installed without knowing it, some of which transitioned without being aware of it simply because Chrome replaced the default browser and imported all settings. For the non tech savvy folks, it basically came down to "the Internet icon changed" .
> Chrome is an adware that is distributed by Google
I don't really disagree. They push it in a lot of ways that Mozilla isn't shady-enough to do (thank you, Mozilla). But whatever you call it, Chrome's tactics work.
> Chrome is an adware that is distributed by Google. It is bundled with most of Google products and a huge amount of software setup, because Google pays publishers some pennies for every new installation.
On top of that gmail/google users receive email SPAM about installing Chrome each time they log into a new computer.
You never asked for it and can't opt out. They've basically crossed the line where they can't be discerned from regular email spammers. All in the name of killing all non-Google browsers.
Also remember that for years people have crucified Firefox for being technically inferior to Chrome. They claim to just use the better browser. And the technical argument they are making, that having so much of the browser exposed made keeping up so much harder (with multi process just rolling out now), makes a lot of sense.
Looking at the decisions made maybe the problem is that they made the multiprocess jump first. If they had said two years ago: we are going multiprocess and we need to deprecate XUL plug ins to do so, it would have gone over a lot better.
Google Chrome is kind of like a sedan, something convenient for most people.
Firefox is kind of like a pickup truck, less convenient for a lot of people but more powerful and useful for the people who need them.
This move is kind of like a pickup truck manufacturer realizing that sedans are more common than pickup trucks, then thinking sedans don't have beds in the back, and removing the bed from their pickup truck. Then afterwards, they're confused why people don't like this change.
A more accurate metaphor would involve the sedan have modern safety features the lack of which make the truck increasingly risky to drive but which the truck is unable to adopt without shedding technical limitations imposed by the bed.
Except in this case it's like removing the bed so I can't hypothetically transport large quantities of nitroglycerin (addons with tracking) but they're preventing me from transporting anything of interest (tab mix plus).
I'll just use the Firefox LTS until it stops working with the modern web. By then hopefully the issue will be solved (perhaps by me, as I'm a dev).
> Except in this case it's like removing the bed so I can't hypothetically transport large quantities of nitroglycerin (addons with tracking)
No? That's not what's motivating this at all.
The problem is the XUL/XPCOM API are fundamentally incomposable with completely sandboxed per-tab processes a la Chromium and other isolating security changes, because of assumptions they impose on Firefox internals.
If you turn on multiple processes in Firefox there's a bunch of complicated shims that half-keep some extensions working some of the time, but it's an uphill battle to support an API that never conceived of the idea. It needs to be shitcanned to move forward.
Sufficient extension points with APIs to reimplement the interesting addons should have been made available and working years before dropping compatibility. From the conversations happening around the most popular addons, that has not been the case.
It may be that the old APIs need to die; but this way isn't the way to kill the old API. You need as near to complete overlapping for a long time to get people to port over. You don't do cliff edges. That's how you kill your userbase.
But this is not a secret. This has been discussed repeatedly for at least 5 years now. The current XUL methodology CANNOT sustain, and everyone knew this.
But everyone also knew Mozilla was famous for putting off being confrontational, so nobody actually thought this was going to happen, so nobody really communicated with mozilla on what would be needed to avoid this happening. Now Mozilla has finally set a date (which maybe they won't push back YET AGAIN), and people who've not been doing work on their extensions in preparation for this, or who did not talk to Mozilla about what they need when Mozilla repeatedly asked for that information, are suddenly afraid that they're going to be left in the cold.
Mozilla does almost absolutely everything on public lists. This is all completely readable. The common thought was "they're not really ever going to do this, so we don't really need to present them with what we need, because we know they won't do this." So what else can Mozilla do? Nobody actually believed they were going to really set a cut off date. Everyone thought it'd just be pushed back over and over like it always has been.
> The current XUL methodology CANNOT sustain, and everyone knew this.
Yet we still don't have a replacement for even a tenth of what it could do today!
Once Firefox 57 is released, I'll lose the ability to use Firefox at all, and won't be able to regain it for several years. Just because no one though to consider what APIs one might have to provide before deprecating the old ones.
Partially because when Mozilla initially said "XUL is going away, what do you guys need?" Everyone just laughed at them and said "No, it's not, you'll never replace it because it is too important in extensions", and then all went away.
Where are the specs for what replaces it supposed to come from? And when they asked for those specs and got little answers, what were they supposed to do? Run around screaming "No we're serious this time, we really are going to drop this, and we really need you guys to work on getting requirements voiced? And also it'd be great if you took us seriously about e10s too!"
One of my favorite extensions is vimperator. There are comments going back over a YEAR that there would be problems with e10s and XUL, and they were always just pushed off and ignored because it wasn't a current situation. I've got two or three other extensions whose github issues section mirrors the same situation. Some of them thought Mozilla would put in a "allow me to run dangerous addons" button and leave the code in play, but if add on developers can do that, then malicious add on developers can too.
Did you request this with your plugin/addon developers, or with mozilla yourself through their many methods of contact for this if you are a plugin/addon developer?
I don't get why addon/plugin developers not communicating upstream is the problem of upstream.
Yup, this is one of the developers that took it serious [0]. You can see, he started preparing in August of 2015. If other developers did that, this info wouldn't be a problem.
IPFS is a one off though, it has multiple paid developers who can spend their full time rewriting their addons at the drop of a hat. Plus that IPFS addon didn't require deep access to Firefox's internals, which many popular addons do.
This call for, "Just tell us what APIs you need!" is missing the point.
1. There's no guarantee that Mozilla will actually implement such APIs, and no guarantee that they will actually support them in the future. If past behavior indicates future behavior, they will support them for 12-18 months and then say, "It's not worth the effort anymore. But here's a new bundled Facebook plugin that we're totally not being paid to put in. Have fun!"
2. More importantly, many of these extensions would never have come to exist if their authors had had to beg Mozilla to implement an API first. If XUL had never existed, would ad-blocking extensions have ever been created? I can imagine the Bugzilla pages now: "This is not a priority for our limited manpower. Restricting this issue due to advocacy. You can discuss it further on the mailing list."
The problems with XUL have been discussed for over 5 years, but there hasn't been a solution. WebExtensions was announced 18 months ago, was deemed stable for developers 8 months later, and only just got a reasonable migration path with embedded WebExtensions in Firefox 51.
There's been plenty of communication from developers on Bugzilla. People are alarmed because Mozilla's original estimate fell way short, the deprecation roadmap is a lot more specific than the implementation roadmap[1], and migration is going to suck for extensions that need APIs missing from Firefox 52.
I don't think this is accurate. The handwriting has been on the wall for years, and I've had no doubt that Mozilla would actually rip out XUL and leave millions of loyal users hanging. Mozilla has been on an anti-existing-user trajectory for years now.
We have loudly protested. We have explained in excruciating detail how Firefox without XUL is not Firefox, and how a non-XUL Firefox will not meet our needs.
The correct response from Mozilla would have been to make XUL work with e10s, regardless of whether it's easy or fun to do so. The actual response from Mozilla has been, "Nah, that would be too hard. Besides, you don't really want XUL, because it lets in the malware bogeyman. We'll just rip it out. Don't worry, you'll thank us later."
This is heard as, "We don't care about you. We don't want your kind of users. We want those users, the ones who have switched to Chrome. You can sit on an old, outdated version until it won't load web sites anymore, and you can be constrained to the dustbin of history, where you belong."
I've no doubt there are Mozillians who do not feel that way (e.g. the Pentadactyl developers who work at Mozilla and quietly update it to work with newer versions), but that is how the message from Mozilla comes across. Most importantly, that is the net effect of Mozilla's policy.
Yes, Firefox is supposed be more like a hobbyist's car, optimized for tinkering and non-mainstream features.
Except that one day they're suddenly disallowing core features that such hobbyists care about. Suddenly, they don't allow manual transmissions "for security reasons" (you try to plug one in and the internal computer shuts down and refuses to boot, even though you set the computer to expect a manual).
And they've worked with transportation agencies to ensure that their cars get pulled over when they're using a manual.
I was so upset that I wrote a hitler parody when FF stopped supporting unsigned addons even when the user finds the settings and authorizes it.
Your comment is insulting, people are not "less than smart" because have different priorities or different view than you. I am using mostly Chrome because I had a lot of performance/memory usage issues with Firefox and because of security.
You forget how someone got access to internal not disclosed list of vulnerabilities in Firefox?
It's innovator's dilemma. The same thing that made Mozilla popular ("advanced" add-ons) is what kept it from moving to the "dumb" Chrome extension model that Google's browser adopted a long time ago. The older add-on model is what kept it from having better security and having less memory problems for so long.
There are still tons of technical people (myself included) who use Chrome because Firefox became bad. The only reason I even have Firefox installed at this point is for extensions like DownThemAll - which will disappear after this move.
The years of firefox memory leaks completely turned me off the product.
> Ouch, the comments over there are extremely negative.
Humans are loss-sensitive.
When Coca-Cola did blind taste tests for New Coke, it was overwhelmingly preferred. When they told people which was which, the preference for New Coke increased. Instead, when they removed Coca-Cola Classic from the shelves, people clamored for it back. People want the thing they cannot have. Scarcity creates desire.
To some, this is a simple engineering trade-off. You can't have sandboxing, tab isolation, and responsiveness improvements with XUL add-ons in any kind of feasible or sustainable way. You can estimate how many people use add-ons that can't (or won't) be ported to Web Extensions, how many people would benefit from the proposed improvements, what the relative changes in user adoption are likely to be for each, and make a call that gives the best result for the whole Firefox population.
But that won't stop the people who are feeling the loss from being vocal about it, nor others who don't even use those add-ons attaching value to the thing they can no longer have, and resent that it's being taken away.
To reverse course now would fail the other way: if you tell people you're going to hold off on full e10s deployment and the security and responsiveness improvements that will come with it to allow XUL add-ons to remain a while longer, they'll be upset that you've taken away the improvements you promised.
Both times the conversation will only be about one side of the equation. No amount of marketing will fix that. Just ask Coca-Cola.
> To some, this is a simple engineering trade-off. You can't have sandboxing, tab isolation, and responsiveness improvements with XUL add-ons in any kind of feasible or sustainable way.
Certainly you can: it's software--anything is possible.
The issue is that they don't want to make the effort. I think this is because the developers are no longer the people who built Firefox, and they want to reinvent Firefox and put their own stamp on it--IOW, it's NIH.
I think it's also a matter of the higher-up execs and board members having non-technical goals. It's similar to when a successful, focused company is bought by a larger one, and its popular product is canceled, its development team reassigned to other tasks in the new company. The users are left hanging, their software/product/service being yanked out from under them. At least Firefox is FOSS, so it can be continued, but of course that takes a lot of manpower nowadays. Hopefully Pale Moon will sustain the vision of the original Phoenix.
> Certainly you can: it's software--anything is possible.
As the IRC channel topic on #jsapi on irc.mozilla.org says, "Nothing is hard to implement in isolation."
No, not everything is possible given finite resources. Some things are possible only if you sacrifice others. That might be actual things you need to remove, or the opportunity cost of adding more complexity to satisfy contradictory constraints and hence not improving something else.
As a concrete example here, if you have an extension model that relies on synchronous access to the page DOM _and_ the UI at the same time, and now you want to put those two things in different processes, you have a few options:
1) You can throw out the extension model.
2) You can write some complicated synchronous IPC proxies.
Make no mistake, option 2 _does_ mean trading off responsiveness: if the web renderer process you are trying to poke at is busy, then you will end up having to wait, and if you wait in a sync proxy that's a pause in the UI process. And that's what you're trying to avoid in the first place.
Note that people did in fact create the sync proxies, as a temporary measure, while working on providing better APIs to be used instead, to make the transition easier for extension authors. There are conflicting opinions on whether this is the right time to get rid of the sync proxy bits, but it does in fact need to happen at some point.
As for your opinion that "the developers are no longer the people who built Firefox", here's another data point. My first commit to Gecko (this is before there was a Firefox) was sometime in June 2001. I'm not trying to reinvent anything for the sake of reinvention. But I do think there are fundamental problems with both supporting the existing XUL addon ecosystem and making a number of long-delayed architectural changes that we don't feel like we can delay any longer. Again, we can argue about whether this is the right time for those changes. But I think it is. As a simple example, needing to support the existing XUL addon ecosystem would make the Stylo project (using the Servo style system in Gecko) harder. So if we're trying to get Stylo done by sometime this year (which we are), that gives you an end-of-life of ... well, right about the Firefox 57 release.
I last used Firefox in December 2017, and there was something else weird that made me stop using it.
I'm waiting for Mozilla servo to be released as a standalone browser that doesn't use more memory than chrome, and doesn't have trash font support. Right now it's worse than chrome for battery life and RAM usage on Windows.
November 14th. I really hope they get the promised additional APIs in order until then, but it seems like a really short time (given how they are not 1:1 Chrome yet last I checked). I personally don't mind the switch to much (since I really want better performance, and the beginning of e10s has helped, and I don't care much about non-trivial add-ons), but it's clear the promise of "We'll make new APIs for add-ons that need them" was important.
Getting the APIs in place isn't enough, though; there needs to be time for the addons to adapt too (or for new addons to show up to replace the old ones). I'm not sure they have planned enough time for that to happen, but time will tell.
I use Vimperator. I have not upgraded Firefox since 43.0.4 in order to continue to use Vimperator. I will not upgrade Firefox past the point where it does not support Vimperator.
Some of us who use Vimperator use it not only because of the key binding, but also for the command-line, ability to modify the UI (e.g. :set gui=none), ability to put .vimperatorrc in .dotfiles and use it across multiple systems, and such. As far as I know, VimFX still not capable of all these functionalities (some due to difference in mission, e.g. not modifying the UI.)
That said, WebExtensions at its current state still couldn't support all of VimFX's current feature either.[1]
Note that they do very different things from each other AND that they are running Chromium which is a SUBSET of the plugin features that will be available in Firefox (if all goes well).
cVim AFAIK implement the command line mode by injecting the command UI iframe and key binding events to every webpage as a content script. It works, but still less than ideal than what VimFX is trying to do by binding the shortcut globally.
There's also an ongoing discussion to try to port Vimperator to WebExtensions[1], which having everything as content script might be one way to do. However, it still doesn't give an ability to modify the UI as XUL/XPCOM Vimperator does.
> Note: Firefox 51 requires Vimperator 3.16 which is being reviewed by Mozilla and coming soon. For now, you can get the release on GitHub. However, in order to install unsigned add-ons (like releases on GitHub), you must use the Developer Edition of Firefox and after that open about:config and change the xpinstall.signatures.required property to false.
According to NetMarketShare stats [0], Firefox is now at under 12% of desktop marketshare... and falling. I've switched over to Chromium (and Safari on OSX) because I just couldn't justify slower speeds and much poorer performance overall anymore. I've also noticed it used a lot more CPU than alternative browsers... which is an issue if you're using a laptop. Once Mozilla kills off XPCOM and XUL-based addons [1], there won't be any real reasons left to use Firefox. Lots of Firefox die-hard users I know have already moved to Palemoon which will support XPCOM/XUL addons for the foreseeable future [2].
It's amazing to me how badly managed Mozilla is these days. They've been on a downward slope for the last two years and they still haven't done much to improve their position. Last week I checked Mozilla's homepage and couldn't even figure out what their guiding purpose is anymore. They seem to care more about social issues than about browsers and technology [3]. Unfortunately, they don't have much future.
> I just couldn't justify slower speeds and much poorer performance overall anymore... once Mozilla kills off XPCOM and XUL-based addons, there won't be any real reasons left to use Firefox.
Now, make an enlightened guess as to why they're getting rid of XUL.
> I just couldn't justify slower speeds and much poorer performance overall anymore... once Mozilla kills off XPCOM and XUL-based addons, there won't be any real reasons left to use Firefox.
Well now you don't have to, Firefox is now faster than Chrome by a huge margin with the 51.0.1 Electrolysis update.
My first reaction was to disable automatic updates of Firefox. I'm not against change, but the whole controversy around this issue makes me a bit wary of blindly trusting Mozilla.
I want to make sure my browser experience doesn't get ruined because of this shift. I don't have the time or patience to clean up a messy first release with webextensions only, breaking my trusted browser add-ons. First seeing, then believing.
Is there a quick way to check whether or not specific add-ons are supported in the new version? I'm addicted to tree based tabs (100's of them open at the same time) and Scrapbook. Without those two I would have a very hard time to get through my workday.
> And the theatre analogy is just silly. It's not like shutting down a theatre because someone got shot in it, it's like enacting a "no guns in this theatre" policy instead.
"No guns here" means "Shooters, you will have zero resistance here. Enjoy!".
This is a perfect example of why using hot button issues as an analogy is always a bad idea.
A browser add-on is not a gun. A limited API is not a sign in a window telling you you can't do something, it's a hard restriction that makes breaking rules impossible.
So can we please, please, not turn this into a conversation about gun control? We don't even need an analogy. Everyone here understands browser add-ons.
in about:support is your GPU composting enabled under graphics? I would recommend to refresh Firefox on that screen as well. Also you can check "about:performance" to see which extension is fucking you over.
I would recommend using adblock plus instead, as it is many leagues faster than UBlock Origin in Firefox since version 48 I believe (They optimized their code with Mozilla a couple months ago). Just make sure you go into the adblock plus filter preferences and uncheck "Allow some non-intrusive advertising" problem solved.
+1 Firefox user for the better add-ons. The ones in Chrome/Chromium just haven't seemed as effective for me. Reading people's comments here, I'm actually learning about some add-ons I might add to Firefox! (tree style tabs, Vimperator)
And thanks to Debian, I appear to be using Firefox 45, so I guess the changes people are talking about won't hit me for awhile?
I get that there are a lot of people here who are really concerned that, without XUL and XPCOM, there will no longer be a reason to choose Firefox over Chrome.
What I think they overlook is that, right now, it is impossible to recommend Firefox in any case, because it performs so poorly compared to Chrome that no one will take such a recommendation seriously.
I've been using Firefox since back when it was still called Phoenix. I intend to go on using Firefox for as long as it still exists. But it's been a struggle, these last few years. Having to kick over a primary application platform, losing effectively all state save what programs are running, and reboot it every day or two, because otherwise it gets so slow that it's entirely unusable, gets real old real fast. People like to make jokes about Emacs, but even it doesn't do this! My Emacs sessions last months, and die only when the machine loses power or I hose up the environment so badly while experimenting that it becomes unrecoverable without a reboot. And Emacs is thirty years old.
I don't want to switch to Chrome. Its UI sucks and I'm no fan of Google. But if Firefox keeps getting worse, I'll have to. So I am absolutely delighted to see Mozilla making real and tangible progress toward solving that problem. If doing so means deprecating an ancient plugin API that's in any case dangerous and hard to use, I'm fine with that, especially since there is no reason in the world to believe that its replacement will not eventually gain back most of the relatively few capabilities we're losing in the deprecation. Maybe I won't be able to customize context menus for a while. That's fine, if the browser regains the usability it's lost over the last ten or so years.
I understand not everyone agrees with this point of view. That's not a problem. But I should not like this point of view entirely overlooked by those currently proclaiming the imminent death of Firefox.
> it is impossible to recommend Firefox in any case, because it performs so poorly compared to Chrome ...
I understand that this is your experience, but what is the basis for saying this is generally true? It's not my experience; theoretically, can't I also say my experience is generally true?
The experience of Firefox getting slow over time is hardly unique to me. In any case, if it weren't a relatively common problem, it seems unlikely Mozilla would rearchitect the browser to alleviate it, especially given that some users are very distressed by the side effects of the change.
I'm betting it's your addon's/extensions/plugins causing the problem. A bad extension can bring Firefox down to it's knee's just like anything else programmed by Auntie Thelma.
Download Firefox 51.0.1 then in the URL box type "about:support" then look for the line that says "Multiprocess Windows - 1/1 (Enabled by User)" that indicates whether electrolysis is enabled. If it says "0/1 disabled" you will have to manually enable it.
Next you want to check to make sure your WebGL, WebGL2 and GPU rendering is accelerated under Graphics. If that's all good and your GPU is listed, go scroll up to the top right and click "Refresh Firefox"
when you restart it, go back into "about:support" and make sure everything is loading fine. Then you can head over to test it out http://beta.unity3d.com/jonas/WebGLBenchmark/ and then you should behold the power! Firefox should benchmark and run websites very noticeably faster than other browsers. The only exception is Firefox's inability to render forum list heavy sites (It chokes on them), so all other browsers will out perform it on Facebook, Flickr and 500px for the time being until that gets fixed. In fact if you are a heavy Facebook user, Safari performs the best with it, and if your on Windows then Opera gives the best Facebook performance. You can also type in "about:performance" to get a rundown if any plugins are fucking you around.
I'm already well familiar with these tools and this advice, but I nonetheless appreciate you taking the time; perhaps someone else will benefit from their presence here.
Extensions aren't the problem, and Firefox 51 with e10s enabled is amazingly snappy by comparison with the 45 ESR that I usually run.
On the other hand, 51 on Windows also refuses to load or render content from files located in directories mounted via the admin shares (e.g. \\127.0.0.1\C$). Since I use this functionality very heavily (home directory mounted at H:, etc.), I can't really switch over until I've had the leisure to find and resolve the cause of the issue. I have to imagine it's some new security setting that I can modify in about:config, but no one else seems to have run into the same problem, and identifying the changes in config options between Firefox versions is not something I've yet found a way to make trivial.
> it is impossible to recommend Firefox in any case, because it performs so poorly compared to Chrome ...
See that's some odd misinformation that's been spread around since Chrome first was released, it was the fastest browser at the time. Well since then, Chrome and Firefox have been going back and forth on which is the fastest. At this moment Firefox is a good margin faster than Chrome since their Electrolysis update.
So yah, I'm not sure why all this "Firefox is super slow" keeps getting passed around without anything to back it up.
In fact for WebGL Firefox is over 3 times faster than Chrome, so if anything Chrome is actually the old slow dog.
"Well since then, Chrome and Firefox have been going back and forth on which is the fastest. At this moment Firefox is a good margin faster than Chrome since their Electrolysis update."
In benchmarks, yes.
But in the real world, with many different tabs open, where one badly designed website could screw up your whole surfing experience, not so much.
Even thoug it is possible that they fied that behavior by now. I don't know, because since that repeatedly happened, I switched to chrome.
Yah and that's why I included 3 very real world heavy benchmarks that run random multiple real world usage patterns for extended periods of time. An those were the benchmarks that Firefox pulled a head of the pack by a large margin. The basic Java Benchmarks like Sunspider and Ocatane that useless tech sites use to compare the browsers test nothing more then the Java engines of the browsers, pushing numbers while omitting the browsers respected renderers completely.
If we are comparing Chromiums V8 Java engine vs Firefox's Spidermonkey then Chromiums V8 is faster, but would you even be able to tell the difference?
Now day to day usability I am forced to use Firefox because I'm a tab whore and constantly run 80 tabs at all times. When I try doing that with other browsers they choke within an hour to up-to 2 days. Firefox allows me to run ~80 tabs with up-times approaching 2 months regularly. But that's the way I use my browser, other people would care about other features more.
Now of coarse different builds on different OS's you will run into different problems. On my Debian stable box, Firefox doesn't play nice and I'm forced to use Chromium, but on Ubuntu, Firefox performs solid. Now the main reason Firefox is running like ass on some systems is due to having old extensions installed, which forces Firefox to drop HW acceleration and fall back into compatibility mode. The Problem on my Debian box is that Firefox is not loading the WebGL2 drivers (gives me a bad driver error), thus HW acceleration is broken and it runs like ass.
You can confirm this on your install by typing in "about:support" in the address bar. If you are running 51.0.1 you can see if Electrolysis is enabled by looking at the line "Multiprocess Windows 1/1 (Enabled by user)" if yours reports "0/1 (Disabled)" then a shitty extension is forcing it in compatibility mode. You can manually force it on and type "about:performance" to see what extension is the culprit.
Also in "about:support" take a look at the Graphics table, your Compositing should be OpenGL and your WebGL renders should be the name of your GPU without a reported error. You can also "refresh" Firefox at the top right of the page, but if you can't get HW acceleration in FF then use Chromium of coarse, but if you can solve the problem quickly you will have another powerful tool to tackle the web and I'd like to know how it Performs in Arch.
Plus, since you are working with WebGL content it would be great to get Firefox working, cause at the moment Firefox is almost 4x as fast as Chromium on WebGL2 Unity3D.
And thanks for the hints, I will look into that ...
" cause at the moment Firefox is almost 4x as fast as Chromium on WebGL2 Unity3D."
That sounds like asm bonus in Firefox .. and not yet activated wasm in chrome ...
So that might change, as soon Unity can compile to wasm. (or do they that allready?)
But nevertheless, it's good to hear that Firefox still can shine ...
Well, that's good, if you system is so fast, than just use more boxes ... (parameter)
On MY system chrome is still quite ahead of FF. And that was the point, not that you have a good pc ...
(oh and the benchmark is not from me, but actually from the FF dev team itself, as part of emscripten ... and they used to be quite faster than all the others, but apparently not anymore. At least not at the moment ...)
I am wondering if I'm lucky but my foxes are always fast, even with 100 tabs. Both on Linux and Windows boxes.
You are not the first one who complained about the speed here, so I am wondering whether our difference is due to bad luck or good luck.
If your a power tab user, then Firefox is the only browser that can keep up with the 80 or so tabs I always have running, other browsers will will halt to a crawl if I attempted that, either immediately or within a couple days. Firefox allows me to power tab my way through a couple months before I have to restart it, it's just that good.
But there are people that experience the opposite and it's usually due to a shitty extension they have installed. Firefox will fall back to software and disable HW acceleration if an extension is coded like dogwood. In that case the user should check in "about:support" to make sure their GPU HW composting is enabled, that's usually the culprit. "about:performance" will list the extension that's causing the performance issue. Another issue is that Firefox has a hard time rendering Facebook in comparison to other browsers, since most people have Facebook loaded at all times it would for sure give them the illusion that Firefox is slow. I am still looking for a solution for that issue...
They should conduct a survey how many add-ons will stop working, won't be ported to web extensions, and thus how many users they'll lose -- probably not that many because the majority most likely doesn't use add-ons but those people will most likely use anything other people recommend to them. I personally don't know if I'll continue recommending FF.
Firefox has 6.6% market share in browsers.[1] By the time Firefox 57 comes out, Firefox may not matter. Supporting Yahoo Search as the default didn't help.
Mozilla is dropping not only the old XUL interface, but the new Jetpack/Add-on SDK interface that's only worked right for about four years. Dropping XUL make sense; the mobile version of Firefox never supported XUL anyway. But there's no reason to drop Jetpack. That's essentially the same as the WebExtensions API, but with different names for the API calls.
I'll probably convert my one remaining add-on, but it's not really worth it.
Yep. Having Yahoo as the default search has left a bad taste in my mouth. I accidentally used it once and it was all ads above the fold. I had to scroll to see actual search results. Never again.
KeySnail[1] extension, which brings customizable Emacs and vi keys to Firefox, is the "killer app" I use Firefox for and it doesn't have a Chrome counterpart. Without this particular extension I wouldn't have a reason to keep using Firefox.
This is what a fast release cycle gets you: insufficient feedback and a snowball effect as project managers double-down on bad decisions. See also: Ubuntu.
335 comments
[ 5.0 ms ] story [ 360 ms ] threadBut the extension flexibility was one of the major points for me.
I'll have to pin Firefox to 56.x in my package manager.
No browser on Linux can handle different DPI per screen. For Firefox, there's an addon implementing that today, but it won't work with WebExtensions.
So I have to use today's Firefox - or I can't use any browser.
Well, there's also the third option of using a magnifying glass to read websites.
Firefox 57 will have sandboxing and per-tab processes (most likely) plus a better extension system than Chrome's.
Firefox 57 should be at least equivalent to Chromium.
http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?...
http://www.cvedetails.com/product/15031/Google-Chrome.html?v...
During 2016, Firefox had 53 code execution CVE reports.
Chrome had 2.
Firefox only has around 8% of the browser marketshare. Chrome sits between 44% and 60% depending on the source. So it's not a case of Firefox being more popular and attracting more people to target it for hacks. It's just worse software.
And then there's just user inconveniences like how Firefox becomes extremely slow if you open multiple heavy tabs. e10s has yet to fix it, currently, if you enable it, it only opens 2 processes, one for the UI, and one for the rendering engine. So the UI itself might not slow to a crawl but all your tabs will still feel slow if you open heavy stuff.
Firefox also has a slower rendering engine. My eyesight isn't great and I browse web pages with zoom active in between 120% and 150% depending on pages. That makes Firefox behave extremely slow on some pages. It's particularly unbearable, on, say, slashdot pages with lots of comments.
For the same reason smooth scrolling is the first thing Firefox users disable in Firefox. Smooth scrolling works fine on Chrome. FF has never managed to implement smooth scrolling in a way that doesn't slow things to a crawl and makes the scrolling look like stuttering or low framerate.
People often rely on Javascript benchmarks to say "Hey firefox is as fast as chrome!!!11!!" but JS is only one part of what makes a browser fast or slow. What about the parts that actually render the page to something your screen can display?
> Firefox 57 should be at least equivalent to Chromium.
Chrome would have had to stop all development years ago for that sentence to be true.
You can take a look at my results here:
https://www.dropbox.com/s/58doo8csebp9l62/Bench.pdf?dl=0
Each browser has it's strengths and weaknesses it seems, So I run all of them lol For my day to day tab filled behemoth I have to use Firefox, any other browser can't handle the ~80 tabs I have open at once.
In fact me and my roommate have on going challenges on how many tabs we can keep open and up times of the browsers/OS's (He is on Win7). During our battles we have tried tweaking some things and using odd browsers and such, but to be competitive with one another we have to each use Firefox cause it just has that much better memory management/stability.
Here is my latest benchmark as solid proof: https://www.dropbox.com/s/58doo8csebp9l62/Bench.pdf?dl=0
Firefox WebGL works much better on Windows for me; never tried it on OS X. It's probably a Linux-specific issue, but I rarely use Firefox on anything else.
It will list HW acceleration info. You want to make sure electrolysis is running, in the line "Multiprocess Windows: 1/1 (Enabled by user)" should be enabled by default, if it says 0/1 it not active and you will have to manually turn it on.
You can also see if the WebGL renderer is loading properly. On my Debian box it says WebGL2 creation failed (drivers), which would explain my poor performance on that box.
It's worth a shot since Firefox's WebGL rendering is 4x faster then other browsers, it's worth your time taking a quick check.
If you are on a Macbook using battery power I highly suggest using Safari due to it's power consumption profile, your battery will last way longer.
My latest benchmarks: https://www.dropbox.com/s/58doo8csebp9l62/Bench.pdf?dl=0
Rikaichan allows translation of Japanese words simply by hovering your mouse over. It works much better than entering words into an online dictionary, since nearly every free JE-EJ dictionary uses the same source, and if a conjugation isn't translatable it will cut the word off giving the meaning and then letting you easily highlight the conjugation to figure out the meaning of the two together. Its just much faster than using something like jisho.org if theres a lot of words in a text you don't know. Rikaisama makes Rikaichan even more powerful with a lot of extra features
Everytime I've ever tried the similar plug-ins on Chrome they've all been terrible, missing words, missing conjugation, or just being slow in general. Its the first check I do every time I think about switching browsers.
However with the new Electrolysis on Firefox its completely broken and it seems like the dev might not want to do a rewrite since the plugin works exactly how you would want it and has for a few years now, but especially not if the sandbox changes make the plugin impossible to work.
[1] https://chrome.google.com/webstore/detail/rikaikun/jipdnfibh...
The lookupbar is associated with the window chrome (ie. there is one per window). Inserting it into the DOM requires emulating this behavior by synthesizing one "bar" in each tab, adding and deleting them at the right time, etc.
Inserted content always has the possibility of interacting poorly with the scripts and styles of the underlying page (or other extensions). Rikai-chan already has problems where its overlays will end of underneath page content.
Inserted content goes below the line of death (https://textslashplain.com/2017/01/14/the-line-of-death/). There are other minor deficiencies: you can't get the browser's theme on the bar, etc.
For Rikai-chan, it seems like it'd be nice to allow the background script to write to a page that sits on top of the space that shows the actual page and have the content scripts communicate what should be rendered. AFAIK, the only ways to show something on the screen is to either send it to the content scripts and have them modify the DOMs, or show it in a popup for a button.
We need "Safari" for Windows, but not edge.
1) vimperator 2) single process handling multiple tabs (I typically have upwards of 40 tabs open at a time)
Firefox is in the process of removing plugins like 1) so that it makes it possible to remove 2).
Wonderful.
I'm sure they had their reasons for deciding what they did. I still think it's a bad decision.
Vimperator has an issue in it's github referring to e10s and webextensions from 2015. It was commented upon a few times through 2015, more in 2016, and obviously more now. Nobody ever started moving forward. Only 10 days ago, a different issue was opened with regards to porting to an entirely new codebase for vimperator that uses WebExtension. They just now are talking about getting in touch with Mozilla for API requests.
Mind you, a year plus ago, multiple mozilla developers were holding office hours blocked out in the day to explicitly talk to e10s and webextension developers. It got scaled back because nobody ever talked to them and paid developers cannot be paid to do nothing for hours at a time when nobody calls in/emails/etc.
Meanwhile OTHER plugins HAVE taken this seriously, but not a lot of them. Certainly not enough. And yes, that means that you are going to have those plugins lose compatibility. But that's not firefox's fault. Mozilla has done everything they can do to help this transition, including paying people to help, pushing it back multiple times, giving numerous conferences, opening up api requests, and communicating on most every forum available on the internet.
It's on the plugin developers now. That's where your anger should be. Not on the company that is doing, finally, what it said it'd do numerous years ago.
As someone who doesn't follow the nitty-gritty of Firefox development, it's frustrating to only really find out about it when things stop working.
Going back on topic, I've stuck with Firefox for years because of DownThemAll and Firefox Sync. But I stopped using sync a couple of years ago, so that just left DownThemAll... which won't work after this change. So I'll probably leave Firefox behind. Safari supopsedly gives you better battery life on OS X, and Chrome is more popular (i.e., people probably test their stuff on it).
The add-ons might be better, but XUL-based Firefox add-ons are not better. They essentially give full control of your computer to the developer of the add-on. There's no permission model. The "APIs" are mostly the internals of Firefox itself, and when Firefox updates, lots of add-ons break.
Most add-ons can be ported to webextensions. The ones that can't probably shouldn't have ever been add-ons to begin with.
Lots of other browsers used to do the same thing Firefox does, and chose to use a webextension-like model instead. Why? Because those screenshots of folks with half their screen consumed by toolbars, weird popups, overlays in the browser viewport, extensions that sneakily inject ads into pages, and track user behavior _still exist_. And there's really nothing Mozilla can do to stop them.
Do you know how Firefox add-ons get approved? A human sits down and sifts through the obfuscated source code. I helped build these tools years ago, I can tell you it's hell. Beyond being error-prone, it causes months-long delays in add-ons getting approved.
Firefox will be better off for only supporting webextensions.
Really? Name three.
Your arguments may be true, yet they fail to answer the question: "If you hamstring the addons and make everything chrome/chromium like, what's the reasons to use FF then?" If Chrome made all the right decisions, we might as well kill off the Firefox project.
Here's a comparison: https://docs.microsoft.com/en-us/microsoft-edge/extensions/m...
Sounds like Firefox developers will be better off. Everyone else will suffer.
I'm a developer, I understand how much the job sucks sometimes (that's why it's a job). But if you want a product to succeed, can't afford to put the comfort of your developers over that of the end user.
> A human sits down and sifts through the obfuscated source code.
> when Firefox updates, lots of add-ons break
> I can tell you it's hell
It's undoubtedly true that power users will lose a little of the functionality they like in Firefox, but that normal users will have a more secure browser. I'm sure someone will fork Firefox to keep a version alive for those power users.
You might not agree with it, but the logic is sound.
I get it, it's a hard problem to fix. There would be a lot of pain in getting there, both for Mozilla and addon developers. But throwing in the towel feels like a cop-out.
The logic is sound, but so is closing down every theater because someone got shot in one of them. After all, everyone has TVs and blu-ray players now, and you can't get shot in a theater if there are no theaters...
And the theatre analogy is just silly. It's not like shutting down a theatre because someone got shot in it, it's like enacting a "no guns in this theatre" policy instead.
> Instead of allowing open access to the internals of Firefox, which will never be secure
Android, iOS, and many other OSes do this all the time via rather granular ACLs. It can be done.
All analogies are flawed - but Firefox is closing the theaters by completely killing off their add-on interface in exchange for an comparatively shallow experience.
If it were that simple, then the Chrome team would simply have asked the Android team to provide their expertise in designing Chrome's extension API. And of course, it's not like Android provides apps unrestricted access to the hardware (there's a reason that people bother to root their phones). Firefox addons are currently less restricted than Android apps.
Chrome's choice to not use such ACLs has no bearing on whether it is possible or reasonable for a web browser to use. Chrome is not the be-all-end-all of browser technology.
> Firefox addons are currently less restricted than Android apps.
And that's what could be changed. The lack of restrictions in the current state doesn't mean that it can't (or that it shouldn't) change.
Why are these 'normal users' going to use Firefox when their power user friend no longer recommend it, when Google is pushing Chrome as hard as they can on every Google property, and when there are even installers that 'offer' to install Chrome for you? Mozilla can't compete with Google and Microsoft marketing efforts, they can't make anything more than a UI for the most popular mobile browsing platform, and they're alienating power users. Who is going to be pushing Firefox to normal users?
Even PG has remarked in an essay that success isn't easy - the people who will really succeed are the ones who put in the effort to do the hard things.
Of course it's hard. Doesn't mean it shouldn't be done.
> Appealing to PG makes no sense here.
When the argument is being made that it's better to make it easier on Firefox developers at the cost of the user base, the argument made in PG's essay is pretty relevant.
It is being done. That's what people are up in arms about.
> When the argument is being made that it's better to make it easier on Firefox developers at the cost of the user base
As far as I can tell, you're the only one making that argument?
What? kibwen is saying that that is exactly what Firefox is doing!
Bear in mind that this is not just "copying Chrome's API", it's copying the base design (how the manifest works, etc), and adding new Firefox-specific APIs on top of it. The whole idea is that most of the APIs addons need will be added to firefox's webextensions API.
all of this is possible to do with webextensions, just add a contentscript for all_urls. Of course webextensions help with some security issues, but not with the ones you mention.
The one thing that is striking every time I try to use chrome/chromium is just how limited the addon functionality is and how much less freedom the user has. Have you seen "treestyletabs" implementation on chrome? It's a whole other window that has to be started and placed side-by-side with the browser window by user because of the addon limitations. There are also some keybindings which are fixed forever and not allowed to be changed (<C-W>, <C-N> etc).
Of course you can justify the restrictions by bringing up the case of the poor average user who will get abused by his browser having more functionality that he will ever need. But the thing is - I really don't care for the "average user" and its problems. Average user is a beast that is perfectly happy to be contained in the walled garden, but we already have Chrome and Android for that.
I would bet that 99%~ people don't need or even want that kind of absolute freedom. As a chrome user, the only plugin I have that I can't get on the play store is one for downloading youtube videos but I can still install it from the author website, just takes a few extra clicks.
The fact that one doesn't exist. "Developer edition" is really just their alpha build, they don't have release builds that allow unsigned extension installs.
https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded...
https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded...
It seems that those very much exist.
The set of clueless users who would install arbitrary malicious extensions and the set of clueless users who would download and run arbitrary executables is basically the same. Yet if they do the latter, any extention sandboxing is completely and utterly moot. It's the same issue as with mandatory extension signing; requiring signing for extensions while nothing stops someone from downloading an unsigned .exe (which could memory-patch Firefox if it so wished) is absurd.
I do not consider myself a power user of Firefox, but the two extensions I use (DownThemAll and tab groups) are not going to be ported.
Servo has been in Dev for 5 years, so if google isn't working on something to compete with that, Firefox is going to completely dominate the web for years.
When Firefox is no longer an attractive option for power users, the only thing it will have going for it is ideology. And that will not be enough to compete.
I can assure you that you only want this if you can guarantee that your add-ons only do what they claim, don't have security vulnerabilities, and are never acquired and maliciously updated. Otherwise, a permissionless add-on model means a bug in TreeStyleTabs could potentially be used to exfiltrate your entire password database, plant malicious binaries on your system, and destroy local data. If TST had limited permissions along the lines of only being able to manipulate tabs and their UI, that wouldn't be a problem.
> Have you seen "treestyletabs" implementation on chrome? It's a whole other window that has to be started an placed on the left of the screen by user because of the addon limitations.
Firefox will not have this limitation.
Is that a statement about future Firefox visions or Firefox 57? I assume you know the gritty details while I'm a rather confused Firefox power user / fan / advocate (using .. addons that are affected, vertical tabs/tree style tabs plus vimperator/pentadactyl mostly).
The outrage The Internet™ seems to feel is probably not about XUL being deprecated/killed. I'd say no user cares about the technology, the only people even caring are probably the addon developers.
From what I can tell, the outrage is mostly due to the impression (and I dearly hope that you will dismiss this as wrong, just like the 'addon limitation' reference above) that the web extension switch happens before popular, polarizing addons are even remotely possible given the new API.
"Will not have this limitation", as in "it won't support that use case in 57 at all" or as in "you can do better than this Chrome extension you describe"?
You're basically correct about the APIs, though. Developers of some popular add-ons don't know when or if the APIs they need will be implemented. Support for migrating gradually (embedded WebExtensions) was just released in 51 and will be gone in 57 -- not even a full ESR cycle.
Developer burnout is a problem, too. This comes right after many of them put in significant work making their now-deprecated code multiprocess-compatible, which came after mandatory extension signing, which came after a bunch of UI changes. It's not surprising some of them have quit.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1208596
Most of these changes and their timelines are motivated by fundamental architectural work happening deep down in Firefox. We're doing the best we can to get as many add-on APIs in place before 57, but for heavy add-on users, it has the potential to be a rough transition.
For deeper meddling in the browser, and for APIs that don't yet exist, WebExtension Experiments (https://webextensions-experiments.readthedocs.io/en/latest/i...) should provide a reasonable option. Basically, you can keep using old-style "bootstrapped" add-ons in DevEdition and Nightly. Kind of an explicit way to opt-out of API stability guarantess so we can continue refactoring the browser core. Experiments are intended for prototyping new WebExtension APIs for eventual inclusion into mainline Firefox, but you could also use them for power-user APIs, so long as you don't mind the maintenance burden.
Can you clarify/elaborate? Last I heard, UI modification by web extensions was still unconfirmed at best.
Can I use this to replace the entire browser history system and omnibar autocomplete with a custom one?
Can I use this to replace the entire browser chrome?
Some of these changes I need (AutoHiDPI) to use a browser at all. Others I wish for. All of them I currently am using.
The alternative is me staying on an ancient browser, or forking Firefox and browsing with a horribly outdated and barely patched version. Or reading HN with a magnifying glass.
Generally, the way forward will be to use WebExtension Experiments (https://webextensions-experiments.readthedocs.io/en/latest/i...), which let you run classic-style "bootstrapped" add-ons in Firefox Developer Edition or Nightly. The intended use is for prototyping new WebExtension APIs for eventual inclusion into mainline Firefox, but nothing limits you to that usage.
In fact, the per-screen HiDPI setting even has an environment variable on most Linux systems (Qt’s QT_SCALE_FACTORS), but Firefox completely ignores that.
I don’t have the time anymore to rewrite half the UI stack of every single application I use, and then take over maintenance of that. I’ve done that with a few open source projects, but my time is limited. And if I wanted to implement extending the UI properly, I’d definitely have to rewrite the entire stack, similar to what Browser.html does.
https://www.palemoon.org/
But neither of them is good enough. (Especially Palemoon’s UI is painful to look at, and hard to fix).
Owning the code that runs on your machine is your right as a user of open-source software, but there's no right that says that Mozilla must be the one to maintain that code. And nobody's asking you to maintain your own personal fork either: find all the other people who care about unlimited (if fragile) browser extensibility via unrestricted addons and form a community (or hell, a corporation) to collectively make the browser you want, starting from a fork of Firefox (or Chromium, or Midori).
If you believe that there are enough people in your position to make such a collaboration successful, then you're all set. And if you don't believe that there are enough people out there who care about unrestricted addons to make such a project viable, then--while I sympathize with your plight--maybe it makes business sense for Mozilla to drop support for unrestricted addons, especially due to the ways that this feature hinders all the other features that Firefox users are clamoring for: speed, reduced memory usage, speed, HTML5 adoption, speed, ES6+ adoption, speed, speed, security, and speed.
And there's no right that says I have to use FF. They are giving up one of their big advantages.
Source on me saying that? I think they are making a few dumb decisions, but that's putting a lot of words in my mouth.
FF has very few advantages. They aren't competing on speed, mind-share, ease-of-use and now they aren't competing on reliability of add-ons. I get that this can help them focus, but pushing away their limited user-base is like using an axe to help a sinking ship.
This statement is contradictory.
>They essentially give full control of your computer to the developer of the add-on. There's no permission model.
Yes. I know. That's why it's better.
>Most add-ons can be ported to webextensions. The ones that can't probably shouldn't have ever been add-ons to begin with.
You're pushing a worldview here in which some entity - Mozilla, presumably - sees fit to decide in what way I should, or should not be able to extend my web browser. I reject this premise.
The whole point of XUL/XPCOM, as you yourself seem to realise, is that it naturally exposes browser internals and thereby enables permissionless innovation. The only reason WebExtensions can even support the use cases it can is because Mozilla basically looked at the popular addons and defined it to be able to support corresponding functionality. Extension developers finding gaps in WebExtensions APIs were invited to communicate this to Mozilla - that is, to ask Mozilla for permission to extend the browser in a certain way (and for them to allocate manpower to adding that API, etc.)
The idea is to make WebExtensions politically palatable by happening to support what's popular, but that very approach proves the impracticality of the premise. If ad blockers were invented tomorrow, would there be a WebExtensions API? Probably not. Would Mozilla bother to allocate manpower to adding an API for it when one person has the idea and asks? Probably not. If Firefox (and before that, Mozilla Suite, etc.) had had only WebExtensions-like APIs from day one, would ad blockers exist today? Probably not. Ergo, we can conclude that future, yet unconceived innovations will be prevented by this change. The "ask us to add an API for it" approach is not acceptable, given that the technology to make this a non-issue (XUL/XPCOM) already exists and is in use.
>Lots of other browsers used to do the same thing Firefox does, and chose to use a webextension-like model instead. Why? Because those screenshots of folks with half their screen consumed by toolbars, weird popups, overlays in the browser viewport, extensions that sneakily inject ads into pages, and track user behavior _still exist_. And there's really nothing Mozilla can do to stop them.
This isn't Mozilla's problem, and as you yourself acknowledge, trying to save users from themselves is a futile effort.
>Do you know how Firefox add-ons get approved? A human sits down and sifts through the obfuscated source code. I helped build these tools years ago, I can tell you it's hell. Beyond being error-prone, it causes months-long delays in add-ons getting approved.
If this upsets Mozilla, they could get out of the extension approval business. Nothing obliges them to intermediate themselves in this way.
No version of Firefox which implements restrictive code signing practices will ever touch any system I control. Currently I use Firefox Developer Edition. It doesn't appear it will be updated after version 56.
That's the entire point. Firebug could not have existed as a WebExtension, and thus without XUL addons the entire web development field could still be on Venkman or Script Editor rather than where it is now.
The XUL extensions model allows extensions in ways unmatched by WE, and yes the development experience isn't tremendous and it's a serious security risk, but that means it's possible to experiment or customise in ways WE don't allow. Users could get things like NoScript and greasemonkey and ad blockers and tree-style tabs without having to demonstrate its value to the browser developer and needing to get the tool itself or some necessary API integrated and merged into the browser.
> Most add-ons can be ported to webextensions. The ones that can't probably shouldn't have ever been add-ons to begin with.
That is utter garbage.
This means I will now have a zoo of old outdated browsers. Safari 5.1 Win32, Firefox 56 Win32 with Firebug addon, IE11 on Win7 (plus Chrome, Vivaldi and Servo alpha)
I have hope in a lightweight reboot of Firefox based on Servo with HTML based UI (like Firefox was a lightweight reboot of Mozilla Suite; funny that Firefox is now many times more bloated than Mozilla Suite (now called SeaMonkey https://en.wikipedia.org/wiki/SeaMonkey ) and has less features)
(I use a separate Firefox instance for development, and it's not my number one browser for years because it can't handle hundreds of open tabs - IE and Chrome excel on that (my) requirement for 10 years.)
For real. I understand the security argument, but that poster and Mozilla in general seem to be making the argument that "no, you're wrong, you don't know what you want, we're going to tell you what you want, and it's a less feature-rich Firefox."
Well, I use Firefox, and I evangelize Firefox to everyone I know, on the basis, essentially of the extensions, and most of the popular Firefox extensions would have never come into existence with the new extension model. Mozilla is developing APIs to grandfather some of them in, but they're still reducing the possibility space from "anything" to "what we expose through these APIs", so new extensions that change everything will no longer come into being.
And aside from that, they don't even cover everything; I've already been notified by the developers of two extensions I use that they either can't or won't be switching over.
I really do have to agree with the people who are saying Mozilla has totally lost the plot. I've disabled automatic updates until I can figure out what I'm going to do.
XUL does open up more attack surface than a web extension. However, web extensions open up enough that you're already in the business of trusting the creator of the extension.
A web extension is fully capable of stealing my online banking credentials, for example.
But so is every other type of add-on. You even need to upload source code for binary components. (A XUL extension can include DLLs or their cross-platform equivalents.)
Those were my thoughts exactly.
And tangentially related to your point, I am wondering why the addon developer, who I have explicitly trusted by intentionally installing their software, is not at least on the same or even higher level of trust as an unknown 3rd party web developer whose arbitrary Javascript application the browser automatically installs and runs when I visit a desired 1st party website?
There are no built-in protections that Firefox (or any browser) provides for running arbitrary 3rd party code that happened to be included by an unsuspected website that features 3rd party fingerprinting, tracking user actions, access to DOM, whether for "benign" or malicious purposes. In my mind that is just as, if not more, important for both security and privacy.
It looks like it is yet to be seen whether Mozilla's extended WebExtensions API will provide enough for existing add-ons that use current low-level access that to some level restrict 3rd party web applications.
IOW, the addons are software, just like Firefox is. That is what makes them useful.
> Most add-ons can be ported to webextensions. The ones that can't probably shouldn't have ever been add-ons to begin with.
I hope you realize that this attitude is 100% the opposite of the original Mozilla team, and that Firefox and Mozilla would not exist today if it had been. Firefox became what it is today because of its customizability and its empowerment of users.
> Firefox will be better off for only supporting webextensions.
On the contrary, it will no longer be Firefox. That is the point that we 15-plus-year, loyal users have been trying to drive through the thick heads at Mozilla.
If I wanted to use a browser like Chrome, I would use Chrome. What kind of product manager thinks he can beat his competitor by essentially duplicating their product, when there is no differentiation on price? Both browsers are free. People are already using Chrome because Google has what is essentially a Microsoft, IE-style de facto monopoly. People can still use Firefox if they prefer it--but if it ceases to be unique, why would they bother?
Firefox 56 will be the last version of Firefox I use, because Firefox 57 will no longer be useful to me. That is the bottom line.
That way you can use an old version with the old add-on ecosystem for at least a year longer, and still get security updates.
I usually work on Debian Jessie which ships (a variant of) Firefox ESR, and it's very well-usable. I haven't noticed any differences between the latest Firefox on Windows and Firefox-ESR on Debian.
The latest LastPass, XMarks, VimFX, uBlock Origin and uMatrix run on it, though I haven't managed to get RES (Reddit Enhancement Suite) to work.
I don't like all those toolbars that clutter my screen estate, I prefer to browse the web full screen. There are a lot of projects using Webkit, and I also use elinks a lot, but I'd rather support Mozilla and Firefox by using the later when I need a graphical browser.
There are lots of reasons to use Firefox over Chrome. It's not designed to drive traffic to a search engine. It has far better privacy out of the box. It's a standalone browser that isn't tied to the operating system for things like personal certificates. It doesn't lock its settings to the operating system so you lose all your passwords, extensions, and extension settings if you move it from one PC to another like Chrome does. Etc.
It is crazy if you think about it, because Mozilla is the last giant that respects its users. It has a very good proposition with regards to privacy and user-interest alignment.
There are still tons of less-then-smartª people using Chrome. I blame Mozilla for not doing any smart marketing at all.
____
ª Its fair to call it that way. You use a browser more than a car. Yet people do research before buying a car and carefully weigh the downsides versus the upsides. But not for their most important software application in their lifes.
> In the most recent Pwn2Own hacking competition, Chrome came out ahead of every other browser with only one exploit being successfully executed.
0: https://tiptopsecurity.com/what-is-the-most-secure-web-brows...
* Chrome/Chromium is more secure against attacks by governments or criminals (i.e., attacks against the integrity of the system; I can't think of the right word).
* Firefox may be more secure against advertising and corporate confidentiality attacks.
* Firefox with certain add-ons, too technical for most users, may be as secure as Chrome/Chromium.
Firefox, as this announcement shows, is just getting around to freeing itself from design decisions which may have made sense over a decade ago when Mozilla had 'software suite' ambitions but we now know are a liability for something with the security demands of a browser.
It doesn't change your overall point, but I think this part is incorrect. AFAIK abandoning those ambitions was the reason they left Seamonkey behind and developed Firefox.
https://gilbane.com/2000/03/netscape-announces-gecko-adoptee...
Support for XUL addons is being dropped now. That's a long echo.
I'm not sure how that applies. Firefox wasn't magic; Mozilla rewrote their browser intentionally and put a lot of resources into it.
> Firefox started well before Seamonkey was spun out
My understanding of that statement is that they didn't drop the old product until the new one was succeeding in the marketplace. I'm not sure how that impacts what I said.
No no, they didn't. Firefox and Mozilla (and even later versions of Netscape) share the same architectural underpinnings. That's sort of the intent and cleverness of it, it's really an entire system for writing cross-platform apps, with its own 'language independent' component model, gui layer, etc. The things that made Firefox possible also made all-powerful Firefox extensions possible. Much of that architecture is still around. In the intervening years, it's become obvious this is not necessarily a good way to build a browser. Which is why they are dropping XUL/XPCOM extensions. If they'd 'rewritten' it, they wouldn't need to do that.
My understanding of that statement is that they didn't drop the old product until the new one was succeeding in the marketplace.
I'm talking about common architecture, not products. If you're unfamiliar with it, just scroll through this
https://en.wikipedia.org/wiki/XPCOM
If you are familiar with it, I guess I don't understand what your objection is.
Just compare the amount of code execution CVEs found on a yearly basis and the level of severity of each. Then think of how Firefox has much less marketshare than Chrome (FF sits around 8% and its share keeps going down year by year), so Chrome should be a more interesting target for hacking.
Then come back and tell us which browser has the lesser amount, and when some are found, which is most likely to have the more severely exploitable vuln.
It may be Jesus on a popsicle, but I'm not going to trust something distributed via drive-by-installers, marketed through SPAM and made by the world's biggest data-hoarder and privacy-invader no matter what.
It's adware/malware short and simple.
Make it 100% FOSS. Remove any technical connection to Google. Don't require Google-logon to sync. Only distribute it to users who actually asked to have it installed. Etc etc.
At that point I might consider starting trusting it. Not before.
Personally, I'd at definitely consider using Jesus on a popsicle, if the opportunity arose, just to see what it's like. Not that it has so far, sadly.
Definitely not an option.
I don't want to give those to google. Is that unreasonable?
I don't even know why this needs to be said, because it's fairly obvious nobody on Earth actually does risk analysis this way. I mean, unless you're a programmer with some sort of brain worm infestation, who cannot read between the lines, and have an inability to understand how people in the real world do (and must) operate, clearly.
I realize that some software is more secure than others, and that changes can be made to make it more secure. My point is that you can't simply say "therefore these changes are necessarily good", because there is more to software than security, and those changes often involve tradeoffs in other areas, which have to be weighted. For some of us, in this case, those tradeoffs aren't worth it.
Someone has commented above that it seems like Mozilla management may have been bought off by competitors and may be deliberately trying to run Firefox into the ground. I don't believe this, but given the recent decision-making it's not entirely implausible.
Opera went a similar path ~5 years ago. Most Mozillans don't consider this comparable as Opera was closed-source (and there's this one-track tunnel vision people have around that term), but the similarities are stark. A company with a history of listening to its users and a massive level of contribution to open standards and interoperability, making a product that served a niche userbase extremely well, decided that aping it's mainstream competitor (Chrome) directly would somehow be a good move. Now there's no discernible difference between Opera and Chrome, and no reason whatsoever to choose the former over the latter.
Here is an alternative view I have in mind. The strategy to mimick chrome makes sense, because the masses think this is how the browser -- or as they call it the "internet" -- should look like. Its imho feasible to launch a television and internet campaign promoting firefox after the transition by stressing the privacy qualities. Mozilla has a quality other venders don't have.
By making it a pain free switch a big market share is possible for firefox.
Still, i doubt the current board has this view really in mind. I am thinking if I should apply for a position :)
But that's what FF has been doing for the past ~5 years, and how has their share been doing? Not so well.
Chrome has much more marketing behind it. And it comes from a name that people know and trust. Most people don't know who Mozilla is. And most people don't care about avoiding Google. So if I have two browsers, and the lesser known one is constantly following the other, why would I choose it? I'd rather take the leading browser. It seems as if the FF one is just playing catchup the whole time.
I love Mozilla and FF because it respects me. But it often feels like they are losing that respect just to play follow the leader
> And most people don't care about avoiding Google.
...if that changes, everything changes. Thats the same thing with Signal and WhatsApp. I am positively surprised how easy it is to convert people to Signal and the momentum they are gaining.
Maybe they are betting on the very long term? Tbh, I would expect a more focused marketing from Mozilla if that would be the case. I am almost as much confused as you are.
That's a big "if". How likely is it to change? If history shows anything, not very. Don't get me wrong, I strongly hope they can knock Google off the top spot. But hope doesn't ship units.
So I doubt it would get any new users other than geek folk.
Allow me to be more specific.
Chrome is an adware that is distributed by Google. It is bundled with most of Google products and a huge amount of software setup, because Google pays publishers some pennies for every new installation.
I have seen a lot of people who have had Chrome installed without knowing it, some of which transitioned without being aware of it simply because Chrome replaced the default browser and imported all settings. For the non tech savvy folks, it basically came down to "the Internet icon changed" .
I don't really disagree. They push it in a lot of ways that Mozilla isn't shady-enough to do (thank you, Mozilla). But whatever you call it, Chrome's tactics work.
On top of that gmail/google users receive email SPAM about installing Chrome each time they log into a new computer.
https://www.reddit.com/r/firefox/comments/5srruc/every_time_...
You never asked for it and can't opt out. They've basically crossed the line where they can't be discerned from regular email spammers. All in the name of killing all non-Google browsers.
Looking at the decisions made maybe the problem is that they made the multiprocess jump first. If they had said two years ago: we are going multiprocess and we need to deprecate XUL plug ins to do so, it would have gone over a lot better.
Google Chrome is kind of like a sedan, something convenient for most people.
Firefox is kind of like a pickup truck, less convenient for a lot of people but more powerful and useful for the people who need them.
This move is kind of like a pickup truck manufacturer realizing that sedans are more common than pickup trucks, then thinking sedans don't have beds in the back, and removing the bed from their pickup truck. Then afterwards, they're confused why people don't like this change.
I'll just use the Firefox LTS until it stops working with the modern web. By then hopefully the issue will be solved (perhaps by me, as I'm a dev).
No? That's not what's motivating this at all.
The problem is the XUL/XPCOM API are fundamentally incomposable with completely sandboxed per-tab processes a la Chromium and other isolating security changes, because of assumptions they impose on Firefox internals.
If you turn on multiple processes in Firefox there's a bunch of complicated shims that half-keep some extensions working some of the time, but it's an uphill battle to support an API that never conceived of the idea. It needs to be shitcanned to move forward.
It may be that the old APIs need to die; but this way isn't the way to kill the old API. You need as near to complete overlapping for a long time to get people to port over. You don't do cliff edges. That's how you kill your userbase.
But everyone also knew Mozilla was famous for putting off being confrontational, so nobody actually thought this was going to happen, so nobody really communicated with mozilla on what would be needed to avoid this happening. Now Mozilla has finally set a date (which maybe they won't push back YET AGAIN), and people who've not been doing work on their extensions in preparation for this, or who did not talk to Mozilla about what they need when Mozilla repeatedly asked for that information, are suddenly afraid that they're going to be left in the cold.
Mozilla does almost absolutely everything on public lists. This is all completely readable. The common thought was "they're not really ever going to do this, so we don't really need to present them with what we need, because we know they won't do this." So what else can Mozilla do? Nobody actually believed they were going to really set a cut off date. Everyone thought it'd just be pushed back over and over like it always has been.
Yet we still don't have a replacement for even a tenth of what it could do today!
Once Firefox 57 is released, I'll lose the ability to use Firefox at all, and won't be able to regain it for several years. Just because no one though to consider what APIs one might have to provide before deprecating the old ones.
Where are the specs for what replaces it supposed to come from? And when they asked for those specs and got little answers, what were they supposed to do? Run around screaming "No we're serious this time, we really are going to drop this, and we really need you guys to work on getting requirements voiced? And also it'd be great if you took us seriously about e10s too!"
One of my favorite extensions is vimperator. There are comments going back over a YEAR that there would be problems with e10s and XUL, and they were always just pushed off and ignored because it wasn't a current situation. I've got two or three other extensions whose github issues section mirrors the same situation. Some of them thought Mozilla would put in a "allow me to run dangerous addons" button and leave the code in play, but if add on developers can do that, then malicious add on developers can too.
Or I'll fork, merge all upstream patches down, and work with that.
Currently I have to rely on the AutoHiDPI addon because firefox is otherwise unusable on my system (linux with two screens with very different DPIs).
I also asked for a way to get tab thumbnails done, and to replace the entire bookmark and omnibar system.
But no. Now I'll have to fork Firefox to get a usable browser.
I don't get why addon/plugin developers not communicating upstream is the problem of upstream.
On every announcement regarding this for the past months.
I’ve not gotten any answer, nor has any solution been implemented or suggested.
[0]: https://github.com/lidel/ipfs-firefox-addon/issues/20
> didn't require deep access to Firefox's internals
Quite contrary, it needs to handle new URI schema, override URL origin policy, scan pages, do DNS queries and so on.
1. There's no guarantee that Mozilla will actually implement such APIs, and no guarantee that they will actually support them in the future. If past behavior indicates future behavior, they will support them for 12-18 months and then say, "It's not worth the effort anymore. But here's a new bundled Facebook plugin that we're totally not being paid to put in. Have fun!"
2. More importantly, many of these extensions would never have come to exist if their authors had had to beg Mozilla to implement an API first. If XUL had never existed, would ad-blocking extensions have ever been created? I can imagine the Bugzilla pages now: "This is not a priority for our limited manpower. Restricting this issue due to advocacy. You can discuss it further on the mailing list."
Firefox - XUL != Firefox
There's been plenty of communication from developers on Bugzilla. People are alarmed because Mozilla's original estimate fell way short, the deprecation roadmap is a lot more specific than the implementation roadmap[1], and migration is going to suck for extensions that need APIs missing from Firefox 52.
[1] https://trello.com/b/PC9kB14s/webextensions-roadmap
We have loudly protested. We have explained in excruciating detail how Firefox without XUL is not Firefox, and how a non-XUL Firefox will not meet our needs.
The correct response from Mozilla would have been to make XUL work with e10s, regardless of whether it's easy or fun to do so. The actual response from Mozilla has been, "Nah, that would be too hard. Besides, you don't really want XUL, because it lets in the malware bogeyman. We'll just rip it out. Don't worry, you'll thank us later."
This is heard as, "We don't care about you. We don't want your kind of users. We want those users, the ones who have switched to Chrome. You can sit on an old, outdated version until it won't load web sites anymore, and you can be constrained to the dustbin of history, where you belong."
I've no doubt there are Mozillians who do not feel that way (e.g. the Pentadactyl developers who work at Mozilla and quietly update it to work with newer versions), but that is how the message from Mozilla comes across. Most importantly, that is the net effect of Mozilla's policy.
I'd argue that they are able to adopt a better security model, they are choosing not to.
Except that one day they're suddenly disallowing core features that such hobbyists care about. Suddenly, they don't allow manual transmissions "for security reasons" (you try to plug one in and the internal computer shuts down and refuses to boot, even though you set the computer to expect a manual).
And they've worked with transportation agencies to ensure that their cars get pulled over when they're using a manual.
I was so upset that I wrote a hitler parody when FF stopped supporting unsigned addons even when the user finds the settings and authorizes it.
https://youtube.com/watch?v=taGARf8K5J8
"Why not just shrink wrap the browser and make me buy it from Microsoft at Walmart!"
Compare amount of code execution CVEs[0][1]
Chrome = 80
Firefox = 700!
And I don't call Firefox users stupid.
[0]http://www.cvedetails.com/product/15031/Google-Chrome.html?v...
[1]http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?...
The years of firefox memory leaks completely turned me off the product.
Humans are loss-sensitive.
When Coca-Cola did blind taste tests for New Coke, it was overwhelmingly preferred. When they told people which was which, the preference for New Coke increased. Instead, when they removed Coca-Cola Classic from the shelves, people clamored for it back. People want the thing they cannot have. Scarcity creates desire.
To some, this is a simple engineering trade-off. You can't have sandboxing, tab isolation, and responsiveness improvements with XUL add-ons in any kind of feasible or sustainable way. You can estimate how many people use add-ons that can't (or won't) be ported to Web Extensions, how many people would benefit from the proposed improvements, what the relative changes in user adoption are likely to be for each, and make a call that gives the best result for the whole Firefox population.
But that won't stop the people who are feeling the loss from being vocal about it, nor others who don't even use those add-ons attaching value to the thing they can no longer have, and resent that it's being taken away.
To reverse course now would fail the other way: if you tell people you're going to hold off on full e10s deployment and the security and responsiveness improvements that will come with it to allow XUL add-ons to remain a while longer, they'll be upset that you've taken away the improvements you promised.
Both times the conversation will only be about one side of the equation. No amount of marketing will fix that. Just ask Coca-Cola.
Certainly you can: it's software--anything is possible.
The issue is that they don't want to make the effort. I think this is because the developers are no longer the people who built Firefox, and they want to reinvent Firefox and put their own stamp on it--IOW, it's NIH.
I think it's also a matter of the higher-up execs and board members having non-technical goals. It's similar to when a successful, focused company is bought by a larger one, and its popular product is canceled, its development team reassigned to other tasks in the new company. The users are left hanging, their software/product/service being yanked out from under them. At least Firefox is FOSS, so it can be continued, but of course that takes a lot of manpower nowadays. Hopefully Pale Moon will sustain the vision of the original Phoenix.
As the IRC channel topic on #jsapi on irc.mozilla.org says, "Nothing is hard to implement in isolation."
No, not everything is possible given finite resources. Some things are possible only if you sacrifice others. That might be actual things you need to remove, or the opportunity cost of adding more complexity to satisfy contradictory constraints and hence not improving something else.
As a concrete example here, if you have an extension model that relies on synchronous access to the page DOM _and_ the UI at the same time, and now you want to put those two things in different processes, you have a few options:
1) You can throw out the extension model. 2) You can write some complicated synchronous IPC proxies.
Make no mistake, option 2 _does_ mean trading off responsiveness: if the web renderer process you are trying to poke at is busy, then you will end up having to wait, and if you wait in a sync proxy that's a pause in the UI process. And that's what you're trying to avoid in the first place.
Note that people did in fact create the sync proxies, as a temporary measure, while working on providing better APIs to be used instead, to make the transition easier for extension authors. There are conflicting opinions on whether this is the right time to get rid of the sync proxy bits, but it does in fact need to happen at some point.
As for your opinion that "the developers are no longer the people who built Firefox", here's another data point. My first commit to Gecko (this is before there was a Firefox) was sometime in June 2001. I'm not trying to reinvent anything for the sake of reinvention. But I do think there are fundamental problems with both supporting the existing XUL addon ecosystem and making a number of long-delayed architectural changes that we don't feel like we can delay any longer. Again, we can argue about whether this is the right time for those changes. But I think it is. As a simple example, needing to support the existing XUL addon ecosystem would make the Stylo project (using the Servo style system in Gecko) harder. So if we're trying to get Stylo done by sometime this year (which we are), that gives you an end-of-life of ... well, right about the Firefox 57 release.
I'm waiting for Mozilla servo to be released as a standalone browser that doesn't use more memory than chrome, and doesn't have trash font support. Right now it's worse than chrome for battery life and RAM usage on Windows.
[0]: https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
Some of us who use Vimperator use it not only because of the key binding, but also for the command-line, ability to modify the UI (e.g. :set gui=none), ability to put .vimperatorrc in .dotfiles and use it across multiple systems, and such. As far as I know, VimFX still not capable of all these functionalities (some due to difference in mission, e.g. not modifying the UI.)
That said, WebExtensions at its current state still couldn't support all of VimFX's current feature either.[1]
[1]: https://github.com/akhodakivskiy/VimFx/issues/860
https://chrome.google.com/webstore/detail/cvim/ihlenndgcmojh...
I also use this in Chromium -
https://chrome.google.com/webstore/detail/wasavi/dgogifpkoil...
Note that they do very different things from each other AND that they are running Chromium which is a SUBSET of the plugin features that will be available in Firefox (if all goes well).
There's also an ongoing discussion to try to port Vimperator to WebExtensions[1], which having everything as content script might be one way to do. However, it still doesn't give an ability to modify the UI as XUL/XPCOM Vimperator does.
[1]: https://github.com/vimperator/vimperator-labs/issues/705
However there is one killer feature for me in Firefox, that is the fact that I can:
nmap <C-j> 10j
nmap <C-k> 10k
Chrome has these keys already bound and there is no way to unbind them.
I am adamant about using this configuration because it matches my .vimrc - so I use the exact same navigation in my browser and my (arguably) IDE.
It's amazing to me how badly managed Mozilla is these days. They've been on a downward slope for the last two years and they still haven't done much to improve their position. Last week I checked Mozilla's homepage and couldn't even figure out what their guiding purpose is anymore. They seem to care more about social issues than about browsers and technology [3]. Unfortunately, they don't have much future.
[0] https://www.netmarketshare.com/browser-market-share.aspx?qpr...
[1] https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
[2] https://www.palemoon.org/roadmap.shtml
[3] https://www.mozilla.org/en-US/
Now, make an enlightened guess as to why they're getting rid of XUL.
Well now you don't have to, Firefox is now faster than Chrome by a huge margin with the 51.0.1 Electrolysis update.
Proof: https://www.dropbox.com/s/58doo8csebp9l62/Bench.pdf?dl=0
I want to make sure my browser experience doesn't get ruined because of this shift. I don't have the time or patience to clean up a messy first release with webextensions only, breaking my trusted browser add-ons. First seeing, then believing.
"No guns here" means "Shooters, you will have zero resistance here. Enjoy!".
A browser add-on is not a gun. A limited API is not a sign in a window telling you you can't do something, it's a hard restriction that makes breaking rules impossible.
So can we please, please, not turn this into a conversation about gun control? We don't even need an analogy. Everyone here understands browser add-ons.
We detached this subthread from https://news.ycombinator.com/item?id=13675485 and marked it off-topic.
Well, today I just switched back to Chromium (but went with Vivaldi this time).
If you disable the extension you installed, you'll probably see a big difference in Firefox performance.
This is why they're disabling those extensions.
I would recommend using adblock plus instead, as it is many leagues faster than UBlock Origin in Firefox since version 48 I believe (They optimized their code with Mozilla a couple months ago). Just make sure you go into the adblock plus filter preferences and uncheck "Allow some non-intrusive advertising" problem solved.
And thanks to Debian, I appear to be using Firefox 45, so I guess the changes people are talking about won't hit me for awhile?
What I think they overlook is that, right now, it is impossible to recommend Firefox in any case, because it performs so poorly compared to Chrome that no one will take such a recommendation seriously.
I've been using Firefox since back when it was still called Phoenix. I intend to go on using Firefox for as long as it still exists. But it's been a struggle, these last few years. Having to kick over a primary application platform, losing effectively all state save what programs are running, and reboot it every day or two, because otherwise it gets so slow that it's entirely unusable, gets real old real fast. People like to make jokes about Emacs, but even it doesn't do this! My Emacs sessions last months, and die only when the machine loses power or I hose up the environment so badly while experimenting that it becomes unrecoverable without a reboot. And Emacs is thirty years old.
I don't want to switch to Chrome. Its UI sucks and I'm no fan of Google. But if Firefox keeps getting worse, I'll have to. So I am absolutely delighted to see Mozilla making real and tangible progress toward solving that problem. If doing so means deprecating an ancient plugin API that's in any case dangerous and hard to use, I'm fine with that, especially since there is no reason in the world to believe that its replacement will not eventually gain back most of the relatively few capabilities we're losing in the deprecation. Maybe I won't be able to customize context menus for a while. That's fine, if the browser regains the usability it's lost over the last ten or so years.
I understand not everyone agrees with this point of view. That's not a problem. But I should not like this point of view entirely overlooked by those currently proclaiming the imminent death of Firefox.
I understand that this is your experience, but what is the basis for saying this is generally true? It's not my experience; theoretically, can't I also say my experience is generally true?
Download Firefox 51.0.1 then in the URL box type "about:support" then look for the line that says "Multiprocess Windows - 1/1 (Enabled by User)" that indicates whether electrolysis is enabled. If it says "0/1 disabled" you will have to manually enable it.
Next you want to check to make sure your WebGL, WebGL2 and GPU rendering is accelerated under Graphics. If that's all good and your GPU is listed, go scroll up to the top right and click "Refresh Firefox"
when you restart it, go back into "about:support" and make sure everything is loading fine. Then you can head over to test it out http://beta.unity3d.com/jonas/WebGLBenchmark/ and then you should behold the power! Firefox should benchmark and run websites very noticeably faster than other browsers. The only exception is Firefox's inability to render forum list heavy sites (It chokes on them), so all other browsers will out perform it on Facebook, Flickr and 500px for the time being until that gets fixed. In fact if you are a heavy Facebook user, Safari performs the best with it, and if your on Windows then Opera gives the best Facebook performance. You can also type in "about:performance" to get a rundown if any plugins are fucking you around.
Extensions aren't the problem, and Firefox 51 with e10s enabled is amazingly snappy by comparison with the 45 ESR that I usually run.
On the other hand, 51 on Windows also refuses to load or render content from files located in directories mounted via the admin shares (e.g. \\127.0.0.1\C$). Since I use this functionality very heavily (home directory mounted at H:, etc.), I can't really switch over until I've had the leisure to find and resolve the cause of the issue. I have to imagine it's some new security setting that I can modify in about:config, but no one else seems to have run into the same problem, and identifying the changes in config options between Firefox versions is not something I've yet found a way to make trivial.
Have you given the Developers edition of Firefox a go? https://www.mozilla.org/en-US/firefox/developer/
See that's some odd misinformation that's been spread around since Chrome first was released, it was the fastest browser at the time. Well since then, Chrome and Firefox have been going back and forth on which is the fastest. At this moment Firefox is a good margin faster than Chrome since their Electrolysis update.
So yah, I'm not sure why all this "Firefox is super slow" keeps getting passed around without anything to back it up. In fact for WebGL Firefox is over 3 times faster than Chrome, so if anything Chrome is actually the old slow dog.
Current benchmark for proof: https://www.dropbox.com/s/58doo8csebp9l62/Bench.pdf?dl=0
But in the real world, with many different tabs open, where one badly designed website could screw up your whole surfing experience, not so much.
Even thoug it is possible that they fied that behavior by now. I don't know, because since that repeatedly happened, I switched to chrome.
edit: oh and about specific performance I know and care about at the moment, because I work with those technologies is that: http://kripken.github.io/box2d.js/webgl_demo/box2d.html?500
On my system (Archlinux) chromium runs much faster than firefox.
If we are comparing Chromiums V8 Java engine vs Firefox's Spidermonkey then Chromiums V8 is faster, but would you even be able to tell the difference?
Now day to day usability I am forced to use Firefox because I'm a tab whore and constantly run 80 tabs at all times. When I try doing that with other browsers they choke within an hour to up-to 2 days. Firefox allows me to run ~80 tabs with up-times approaching 2 months regularly. But that's the way I use my browser, other people would care about other features more.
Now of coarse different builds on different OS's you will run into different problems. On my Debian stable box, Firefox doesn't play nice and I'm forced to use Chromium, but on Ubuntu, Firefox performs solid. Now the main reason Firefox is running like ass on some systems is due to having old extensions installed, which forces Firefox to drop HW acceleration and fall back into compatibility mode. The Problem on my Debian box is that Firefox is not loading the WebGL2 drivers (gives me a bad driver error), thus HW acceleration is broken and it runs like ass.
You can confirm this on your install by typing in "about:support" in the address bar. If you are running 51.0.1 you can see if Electrolysis is enabled by looking at the line "Multiprocess Windows 1/1 (Enabled by user)" if yours reports "0/1 (Disabled)" then a shitty extension is forcing it in compatibility mode. You can manually force it on and type "about:performance" to see what extension is the culprit.
Also in "about:support" take a look at the Graphics table, your Compositing should be OpenGL and your WebGL renders should be the name of your GPU without a reported error. You can also "refresh" Firefox at the top right of the page, but if you can't get HW acceleration in FF then use Chromium of coarse, but if you can solve the problem quickly you will have another powerful tool to tackle the web and I'd like to know how it Performs in Arch.
Plus, since you are working with WebGL content it would be great to get Firefox working, cause at the moment Firefox is almost 4x as fast as Chromium on WebGL2 Unity3D.
" cause at the moment Firefox is almost 4x as fast as Chromium on WebGL2 Unity3D."
That sounds like asm bonus in Firefox .. and not yet activated wasm in chrome ... So that might change, as soon Unity can compile to wasm. (or do they that allready?) But nevertheless, it's good to hear that Firefox still can shine ...
Firefox, Chromium, Chrome, Safari and Opera on OSX
On MY system chrome is still quite ahead of FF. And that was the point, not that you have a good pc ...
(oh and the benchmark is not from me, but actually from the FF dev team itself, as part of emscripten ... and they used to be quite faster than all the others, but apparently not anymore. At least not at the moment ...)
But there are people that experience the opposite and it's usually due to a shitty extension they have installed. Firefox will fall back to software and disable HW acceleration if an extension is coded like dogwood. In that case the user should check in "about:support" to make sure their GPU HW composting is enabled, that's usually the culprit. "about:performance" will list the extension that's causing the performance issue. Another issue is that Firefox has a hard time rendering Facebook in comparison to other browsers, since most people have Facebook loaded at all times it would for sure give them the illusion that Firefox is slow. I am still looking for a solution for that issue...
They have; I've seen the data on some Mozilla blog but I can't remember where.
What about the rest? What about users that are switching to firefox from another browser?
Mozilla is dropping not only the old XUL interface, but the new Jetpack/Add-on SDK interface that's only worked right for about four years. Dropping XUL make sense; the mobile version of Firefox never supported XUL anyway. But there's no reason to drop Jetpack. That's essentially the same as the WebExtensions API, but with different names for the API calls.
I'll probably convert my one remaining add-on, but it's not really worth it.
[1] https://www.netmarketshare.com/browser-market-share.aspx?qpr...
[1] https://www.netmarketshare.com/browser-market-share.aspx?qpr... [2] https://www.netmarketshare.com/browser-market-share.aspx?qpr...
[1] http://gs.statcounter.com/?chart_type=line&statType=Browser
[1] https://github.com/mooz/keysnail/wiki