611–620 of 836 posts
Earlier quoted context omitted.
Self-Destructing Cookies is not a WebExtension, you want Cookie AutoDelete. https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/
Self Destroying Cookies is a WebExtension. There are now a couple of forks.
I just updated - WOW! What an improvement! Compared startup time and scrolling around some over-monetized sites; Behaves just as well as Chrome. Time for a switch again, I've missed FireFox since I started having Chrome as my default browser back in ~2011
If it as just as good as chrome, why should I switch? Especially given how good Chrome Dev tools are.
Earlier quoted context omitted.
especially TreeStyleTab is considerably weakend with the new update (like all extensions that now have to fit into less powerful webextension). From my point it is so bad (I lose 4 out of 6 regularly used add-ons) I am actively considering of leaving firefox for the better.
What do you use? Some things are still a bit hacky, but it all comes together for me. I had everything packed, ready to move, but than came the ports :)
(And I will have to find appropiate replacements for Leechblock and FireGesture)
Earlier quoted context omitted.
> Note that the webextension APIs are still under active development. In which case, switching to webextension support exclusively is premature at this point, don't you think? It would have been better to wait until the API was robust enough to allow 99.99% of legacy extensions to be ported.
Unfortunately, this would have meant no Firefox Quantum. As a Firefox dev (I'm still working at Mozilla, although not much on Firefox atm), I have seen many, many occurrences in which I couldn't optimize codepaths, or even in some case fix bugs, because the old extension mechanism made it impossible. Consider the necessary steps: 1. realize that an internal API is broken; 2. come up with a new non-broken API; 3. port…
Earlier quoted context omitted.
Mozilla doesn't create all those extensions. And the extensions' authors had, what, two years advance warning or so? Criticize the real culpits, not Mozilla.
There's only so much an extension author can do if WebExtensions doesn't expose an API corresponding to one which was critical in the XUL extension. I'm in that position myself right now, having volunteered to take over Firemacs development before I found that there is no way to listen for keypress events in browser chrome. You can only do that in injected content scripts, which don't work except in web content and a…
Earlier quoted context omitted.
Look at this from a user perspective: The user diligently updates Firefox, optimistically hoping that this new version will be as awesome as the previous ones that vastly improved performance. Firefox starts and, suddenly, a bunch of things that used to work stop working. Why? Well, essentially, something that they can't hope to comprehend and that they never asked for and had no input on just ruined their browser. W…
> Users won't blame the extension developers. They will blame Firefox. What's funny to me is that these 'users' you describe are apparently on HN - I thought this place was mostly software devs, but it's striking how many posts seem to fundamentally misunderstand the decisions made by Mozilla. > This is the mother of all breakages I would be that somewhere above 90% of FF users will be unaffected. Given Firefox's mar…
Years, in fact.
Earlier quoted context omitted.
the author of TST is refusing donations AFAIK. He also said a lot of blockages came from Firefox and not from himself. I find it a bit sad that Firefox is not making TST a prime feature of Firefox. Are no Firefox developers using TST? I find that surprising.
It's possible most of them are now using the combination of tab containers and the "snooze tabs" extension, rather than trees. A test pilot feature that lets you mark tabs as "I don't want to see you until tonight/tomorrow morning/the weekend/next week/etc". It really cuts down on the need to keep 100+ tabs open (you just silo the tabs based on their role, then snooze all the ones you don't want to lose but don't nee…
It’s great that FF is now faster but how’s battery life in this new engine? The reason I stuck with safari and only a year ago moved to chrome was that google finally was able to drastically improve battery life on chrome for Mac... where is FF here (their release page doesn’t mention “battery” at all), does anyone know?
Well, I'm running it on a 7-year-old Mac mini (yeah, no battery, I know, but hold on...), and _idle_ Firefox, without focus, is ticking along at 0.7-1.5% CPU time. Safari is zero . Dead still. I type this and it moves to 0.3%. No idea what Firefox is doing... edit: Also, even without focus, Firefox climbs to 8.9% CPU just by hovering my mouse over it. Safari goes to 0.2%.