[Ext] Cookie Controller, now with DOM storage

[Diamanti]

ty

[lithopsian]

ty

Forgot to mention. The exception is temporary, but any cookies it allows follow their own rules and will not be explicitly deleted by Cookie Controller. So you probably want to set session-only temporary exceptions in nearly every case, then the cookies will also expire when the exception does.

[lithopsian]

I'm finishing up version 3.0. It will:
- include menu-button versions of all three buttons, for those that don't like right-clicking;
- re-organise the global cookie settings for the toggle button, hopefully easier to understand and use;
- remove (actually just hide) the menu option to control the dom.storage.enabled preference, too dangerous for general use.

This would be a good time to jump in at BabelZilla and add your own translation. Or there is a half-done French translation just aching to be finished. Lots of Russians out there must be desperate to see some Cyrillic? And I just noticed that Polish is the next most popular locale.

[lithopsian]

Oh and so close to getting an Italian translation! Whoever you were, don't give up now

I've released v3.0 with with the current translations, but don't worry if you have itchy fingers and want to type in some menu labels in your own language. I'm adding some new options now and there'll be new strings to be translated for v3.1.

[lithopsian]

I'm adding a number of "advanced" options. In fact many of them are already in v3.0 in varying degrees of completeness, but only accessible directly through about:config. More on that in a separate post.

My question here is about one possible option. I've been caught out by clicking the tidy button when I didn't really want to. It does what it is designed to do and deletes cookies, but that can be a little too brutal for some people, so I thought an option for the button not to do that would be helpful. It would still be possible to delete from the menus and the button will still indicate the state of cookies for that page.

The question is what could the button possibly do if it isn't deleting cookies? Nothings seems a bit of a waste, but I can't think what else would be useful. Any ideas?

[Alan Baxter]

Maybe we could do without the Tidy button completely. I know I don't use it. Could you "indicate the state of cookies for that page" with the Perm button?

[lithopsian]

Maybe we could do without the Tidy button completely. I know I don't use it. Could you "indicate the state of cookies for that page" with the Perm button?

Certainly. I don't think the majority of people should need the tidy button, but some use it and some have commented that it is too easy to press (when meaning to press a different button or wanting to bring up the menu) and lose a lot of useful cookies. I find it useful mostly just as an indicator of whether or not a domain has cookies stored. It was a late addition, when I could no longer claim "there's no demand for it"

Could you elaborate on how the perm button might indicate the cookies as well as the permissions? I think the icons are already plenty intricate enough and I don't know how I might put more information on it.

[lithopsian]

So here's the new options coming up. In the current release v3.0 they are only accessible using about:config. They are all in the extensions.cookieController preference branch.

stripWWW: existing option for storing exceptions without "www." on the front.
stringSub: existing option for storing exceptions for the base domain.
eachFile: new option to store separate exceptions for each file:/// url instead of one exception for them all. Don't try to use this because it doesn't work yet, and never will for Firefox versions older than 21. Note that all cookies are still stored for the same host (a blank ghost) and are accessible to all file:/// urls.
alwaysPin: pinnable sub-menus are pinned by default when you first open the menu. Try it, should work fine.
reloadPage: reload the current page when an exception of toggle state is changed. Should work in most cases.
reloadAll. reload every page. Apart from the obvious reloading of every tab in every window which might cause you problems, it doesn't always reload every page but give it a try if that's your thing.
reloadOnClose: don't reload pages when a cookie permissions is changed until the menu is closed. Handy when multiple changes are being made on a pinned menu, but it doesn't work in 3.0.
filterCookies: in the cookies dialog, filter the list by the host of the current page. Works fairly well.
filterPermissions: filter the list in the about:permissions dialog. Should also work.
hideTidy: existing option for hiding the browse and remove menuitems except on the tidy button.
confirm: existing option to show a confirm dialog when trying to delete all cookies.
safeMode: this is the option to not just blindly delete when the tidy button is pressed. Doesn't work in v3.0, I'm not even sure exactly how it is going to work yet.

[Alan Baxter]

Maybe we could do without the Tidy button completely. I know I don't use it. Could you "indicate the state of cookies for that page" with the Perm button?

Could you elaborate on how the perm button might indicate the cookies as well as the permissions? I think the icons are already plenty intricate enough and I don't know how I might put more information on it.

I meant add it to the Perm button's tooltip information.

[lithopsian]

I meant add it to the Perm button's tooltip information.

I see. I could add information to the perm tooltip and maybe should (eg. see cookie counts on the toggle tooltip), but I would like to keep the possibility for users to see at a glance whether a page is using cookies or DOM storage. The tidy button is not my favourite thing but it does do this to some extent and I find it helpful. I know from other users that it is far more popular for deleting cookies, whatever I might think of the sense of doing that. So I think it has to stay.

At the moment I'm thinking of just giving the option of a confirmation dialog to prevent accidental button presses doing damage. It isn't the slickest thing in the world but perhaps better than doing nothing at all which could be confusing, even annoying if someone has the option set but actually wants to delete on a rare occasion.

[mundivagante]

Have you removed the dom storage toggle? I really liked this facility....

[lithopsian]

Have you removed the dom storage toggle? I really liked this facility....

Yes, that was me. It is actually still there, just hidden. It occurs to me now that if it was just hidden with CSS it would have been much easier for advanced users to re-show it, but it has a hidden attribute so would need a line of javascript to get it back.

I have removed this option because I don't think the majority of users should be setting this to off. It breaks websites rather than just blocking DOM storage. Blocking cookies should be the way to block DOM storage.

I think for the next release I will hide those items using CSS so a little userChrome.css snippet will allow advanced users to put it back. In what way do you use it? Do you toggle it on and off, or just put it permanently off? If you just want it permanently off, the about:config dialog will show you the preference that turns it off, but I really don't recommend it.

[mundivagante]

What I liked about it was that I could set dom storage to off; and then toggle it on if a website wasn't working - just for that website. Thanks for the quick reply though.

[lithopsian]

What I liked about it was that I could set dom storage to off; and then toggle it on if a website wasn't working - just for that website. Thanks for the quick reply though.

You still can. Blocking cookies blocks DOM storage, and allowing cookies allows DOM storage, temporarily for just the current session, or persistently (for local storage, since session storage is always just for the current session). You can allow DOM storage either by using the toggle button or by setting an exception for the website, including the new temporary exceptions.

Setting DOM storage off with the now-hidden setting causes Firefox to throw an exception whenever a website tries to access it. That is what breaks most websites. Leaving it on and blocking access is handled by most websites, although obviously they won't be able to remember any information that was going into local storage. Setting the dom.storage.enabled preference to true with cookies still blocked does not allow DOM storage, although it does mean that javascript no longer throws an exception when a page tries to access it so things may improve. With the old DOM storage setting off, adding an exception for a website does not allow that website to use DOM storage.

So in summary I think that setting was dangerous as well as unnecessary in almost all cases, hence I removed it. I'm hoping that you will still be able to do what you were doing and use the toggle button to see if websites needed DOM storage to work right. Let me know of cases where this just doesn't seem to work right.

When working with DOM storage there are a few things to be aware of. DOM storage doesn't understand about third party permissions, it is either allowed or not. More importantly, the first-party-only exception which should allow DOM storage actually blocks it entirely (perhaps you could use that as a new kind of setting although it is actually a bug!). It also never prompts you for permission the way cookies can, and if you use the ask setting DOM storage simply won't be allowed. There are also a couple of combinations of permissions (basically session-only exceptions with cookies blocked globally) where Firefox claims there is no local storage even though the website has set and can retrieve local storage items. Strangely, DOM storage is reported 100% reliably (so far as I can tell) by Firefox in private browsing windows, while it refuses to acknowledge that there are any cookies at all.

[lithopsian]

Version 3.1 is released. The various advanced options are now on the tools menu, and a couple of them are also on other menus.

If you don't have a tools menu, you can temporarily show it in various ways, but simplest to right click on a toolbar and check Menus Toolbar. I am still looking into placing the Cookie Controller tools menu on the appmenu, but until the Australis team sort themselves out and decide where that is going to end up (expect an exact clone of the chrome tools menu button, same place, same icon), my plan is on hold.

I have also experimented with time-limited permission exceptions. These are theoretically supported by Firefox, but the implementation is really flaky (presumably why there is no Firefox UI for this function) so these are disabled in Cookie Controller. If you want to try and use them, there is a hidden preference permissionExpires. Try "10m" or "12h" and see what happens. The default blank string means that temporary exceptions expire at the end of the session, which works fairly reliably.