[Ext] Cookie Controller, now with DOM storage

[Diamanti]

Of course it is possible, but it isn't likely to happen. The function works perfectly in all regards. The strict javascript interpreter is just being overly picky about trying to protect me from myself. You must have a non-standard preference setting (javascript.options.strict) to see this message.

Yes, i have it.
It is suffit to add a "return false;" to line 154 of cookieController.js

[lithopsian]

As I said I can remove this warning by adding more code. However, it is unnecessary because the code works perfectly now, and I'm not adding code just to shut up a parser that doesn't understand what the code is doing. Returning false from a popupshowing handler means something very specific: do not show the popup. This would be incorrect since the menupopups are always shown. "return true" might be more correct, but since the onpopupshowing call does not even return a value, it is all irrelevant and returning one explicitly just to have it ignored would be confusing. Also, not having an explicit return statement is entirely equivalent to "return undefined" which is exactly what gets returned from onpopupshowing for these menupopups and which correctly results in the popup appearing. Additionally this function is also called to update popups that are already opened and a return value would be inappropriate, although not harmful.

In short, the code is correct and the warning is wrong. End of story. Strict warnings are warnings for a reason. Often they flag up something wrong, but sometimes they don't.

[Diamanti]

Why not support pages with "chrome://" scheme?

[lithopsian]

Why not support pages with "chrome://" scheme?

And "file://"? As soon as Firefox supports them properly, I will

Seriously, cookies are for HTTP. Anything else is just jamming a square peg into a round hole. file:// and chrome:// URLs don't have domains so they don't work with the permission and exception rules. For example, what is the domain for chrome://CookieController/content/CookieController.js? What is the associated top-level domain? What host should an exception be created for? file:// urls were hammered in to allow for testing of local HTML files, but they don't follow the normal permission rules and they keep breaking. chrome:// urls just shouldn't use cookies, it is asking for trouble.

I did once try to go down the route of supporting any scheme that happened to have an associated cookie but it just didn't make sense.

[Diamanti]

chrome:// URLs don't have domains so they don't work with the permission and exception rules

I understand this, but I found it comfortable to use remove and view cookies and storage.

[lithopsian]

I'd be interested to know which chrome URLs you have that are creating cookies. Since any implementation of cookie management for non-http URLs would be a special case, maybe I could make it even more special and just aimed at particular situations such as yours.

As for storage from chrome URLs, it simply doesn't work properly. Recent Firefox versions are better at viewing DOM storage from non-content principals, but it is even more tightly bound to a domain than cookies. DOM storage simply doesn't exist without a domain (and port and scheme), so there shouldn't be anything you can define as DOM storage for a chrome URL.

[Diamanti]

I have my addons, f.e.:chrome://myaddon/content/index.htm

[lithopsian]

Perhaps I'll have another go at this. No-domain URLs all share cookies and permissions which can get very messy, but they can have cookies so I'll see what I can do to show them.

[lithopsian]

file:// cookies are seriously broken but I may be able to hard-code something that will work. No promises because this is essentially unsupported in Firefox, and a few things just happen to have been shoved in from time to time. DOM storage was broken but starting with FF21 it sort of works, although permissions are still broken.

Can you give me an example of the chrome:// cookie use from an addon that you are talking about? I think this is even more broken. I don't even think chrome scripts can use document.cookie or access cookies in any other way that is meaningful for a web page. But maybe you are actually doing something quite acceptable and I don't realise it.

[lithopsian]

I have uploaded a version 2.7beta with support for file:// URIs. It is a complete hack of course, but it does show cookies, DOM storage, and the correct permissions for a file URI, and it does let you set a cookie permission exception for it. All file URIs get the same permissions and work with the same set of cookies but that's just the way Firefox works.

No chrome, and I don't see any prospect of supporting chrome:// locations. Cookies don't work for them unless you can prove differently.

[lithopsian]

Starting with Firefox 21, it seems that you can set cookie exceptions which apply to individual file paths (the entire url is used in place of the host), so every file gets and needs a separate exception. There is no UI to do this from Firefox, it can only be done from javascript. Also the existing UI for displaying permissions does not work properly if you set a permissions of this type (eg. file:///tmp/test.html). The security/privacy benefits are obvious, but while parts of Firefox (as well as all older versions) don't understand it I wouldn't want to put it into Cookie Controller.

[Diamanti]

Ok, ty, excuse me

[lithopsian]

Should have included the link to 2.7 beta:
https://addons.mozilla.org/en-US/firefo ... /versions/

[Diamanti]

Do you can add in line 886 of cookieController.jsm:

Code: Select all

if(type === "Browser:Cookies"){
if(params===null)params={};
params.filterString=this.modifyHost(uri);
}

and modify line 77 of cookieController.xul:

Code: Select all

oncommand="cookieControllerModule.showDialog('Browser:Cookies', gBrowser.currentURI)"

to automatic show cookie for current page?
Perhaps even in Permissions and Exceptions.

[lithopsian]

I've decided to display the <file> cookies on submenus by path, the way http cookies are broken down by subdomains. Anyone with file scheme cookies is likely to have them from a lot of different files and this could be helpful. There is a bug raised to remove the ability to specify a cookie exception that applies to all files, but no pregress has been made on implementing that change. It would be problematic because there is no way to migrate existing exceptions to the new file-by-file method (not to say they wouldn't still do it!), and also because there is no real UI support for managing exceptions on the file-by-file basis.

I prefer the cookies dialog to open unfiltered. The cookies for the current page are already visible on the browse menus, so the only real reason to open the Firefox dialog is to look at cookies *not* from the current page. The code snippet you show is not appropriate in any case since it ignores the preferences for subdomain pruning. There is a cookieControllerModule.modifyHost() function that automatically returns a string with the appropriate "www." or other subdomains pruned from the current host domain, as specified in the preferences.

On the about:permissions dialog, the current page should get selected once the full list has loaded. Unfortunately, Firefox can take 5 or 10 seconds to finish loading the dialog so you may be bored by then. Again filtering could be annoying and confusing, but it would at least speed up the initial load. I'll think about this some more.