Firefox 44 Deletes Fine-Grained Cookie Management (mozilla.org)
ewhac writes: Among its other desirable features, Firefox included a feature allowing very fine-grained cookie management. When enabled, every time a Web site asked to set a cookie, Firefox would raise a dialog containing information about the cookie requested, which you could then approve or deny. An "exception" list also allowed you to mark selected domains as "Always allow" or "Always deny", so that the dialog would not appear for frequently-visited sites. It was an excellent way to maintain close, custom control over which sites could set cookies, and which specific cookies they could set. It also helped easily identify poorly-coded sites that unnecessarily requested cookies for every single asset, or which would hit the browser with a "cookie storm" — hundreds of concurrent cookie requests.
Mozilla quietly deleted this feature from Firefox 44, with no functional equivalent put in its place. Further, users who had enabled the "Ask before accept" feature have had that preference silently changed to, "Accept normally." The proffered excuse for the removal was that the feature was unmaintained, and that its users were, "probably crashing multiple times a day as a result" (although no evidence was presented to support this assertion). Mozilla's apparent position is that users wishing fine-grained cookie control should be using a third-party add-on instead, and that an "Ask before accept" option was, "not really nice to use on today's Web."
Mozilla quietly deleted this feature from Firefox 44, with no functional equivalent put in its place. Further, users who had enabled the "Ask before accept" feature have had that preference silently changed to, "Accept normally." The proffered excuse for the removal was that the feature was unmaintained, and that its users were, "probably crashing multiple times a day as a result" (although no evidence was presented to support this assertion). Mozilla's apparent position is that users wishing fine-grained cookie control should be using a third-party add-on instead, and that an "Ask before accept" option was, "not really nice to use on today's Web."
I'm overwhelmingly a user of Palemoon rather than Firefox. I am extremely satisfied with Palemoon, particularly given the stewardship Mozilla has provided of late.
I hate what Firefox has become. At this point, It's a marketing company with a technology product, not a technology company. I don't like third party applications being inflicted on me. I don't like the state of flux in the UI that has existed since Firefox 26, the change or removal of features I've been using for years. I don't like arbitrary, zero-notice changes to features I'm using. These are all bad things.
But I'm going to stick with a Mozilla-derived browser for as long as humanly possible because all the alternatives seem worse. I like leaving tabs open. Browsers that use One Process-per-tab will annihilate my available RAM. Chrome (-ium), Opera and Safari all lack privacy and security-related addons that I won't surf without. Edge, with no addon support at all and forthcoming "We're gonna try to use Chrome's!", is a complete non-starter. I need Java in a browser for IT operations tasks. Anecdotally, I see as many issues with fake/bad addons in Chrome's Extensions as I did with BHOs in IE6's heyday.
Chrome has gone from the simple, lightweight option to a bloated mess that duplicates a lot of OS functions. I don't even want to load on a low-spec machines any more. I know it's the web's new favorite, but I'd rather take the ham-fisted marketing driven Mozilla mismanagement any day than live in an ecosystem where Noscript and RequestPolicy aren't really available.
-- I wanna decide who lives and who dies - Crow T. Robot, MST3K
And all 12 people that used the feature will be missed.
When your market share has shrunk to little more than the people who only continue to use your product because it has features that differentiate it from the alternatives, removing those very features is a damned stupid move.
I'm just waiting for them to finish the work currently underway to dump XUL and the current addon API, utterly destroying the current addon ecosystem and fully alienating all remaining users. That will be final stroke in Firefox's Chromification, and its death.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
Some where back in the dim recent past, Firefox's ESCape key no longer meant abort everything and return control completely to the user. No matter if the base html is incomplete, no matter if some goofy-gumdrop JSON cloud-abortion is in progress, or a 302 redirect is in progress. No matter if you'll have to settle for a blank page because CSS cannot decide what color the text will be. Just ABORT. Now the ESC key means hardly anything.
Now in the face of incomplete loads, packet loss, severely delayed DNS lookups, javascript tumors that are busy metastasizing to grow the page from seeds using repeated lookups to unresponsive and overworked database servers --- all of this results in pages that won't stop loading, tabs that will not close immediately, or even pages with visible readable content that will not respond to scrolling requests or link clicks... until... exactly what I never found out.
The purported reason was to save the poor deep data content providers from aborted transactions caused by unwashed masses hitting reload and ESC. I say, if they're overloaded or vulnerable in any way to aborts or identical re-submits they are vulnerable to script kiddies too and someone has not done their job properly or provisioned their servers adequately. I never considered the ability to abort a web load as anything but an intrinsic RIGHT --- until it was taken away. It was,like, what are they thinking?
I've had to force-close Firefox to regain control. And no we're not talking about Flash or embed delays either, I run NoScript. This is Firefox's native process refusing to abort everything under all conditions.
If content providers bite into some apple of complexity (for example) embedding advertising and load sharing schemes that do little tricks (such as) using gobblegook DNS names with low or zero TTL, they deserve to be sandbagged for their effort by the masses until they re-think their decision and (god forbid) roll back in the general direction of 'static' content.
Unfortunately this is something a third-party addon cannot really fix. If ever I was temped to fork a whole project and create a new subculture to fix one aggravating feature=bug this is it.
<blink>down the rabbit hole</blink>