Options/Preferences Dialog, Cookies (or Images, or Popup windows), Exceptions. Type in by hand a host that's permitted to set cookies. *We* all understand that subdomains are also allowed, so yahoo.com gives permission to all of yahoo.com. It seems many users with just slightly too much knowledge do not understand, typing in *.yahoo.com, instead. See for example the opening comment of bug 286232. In fact the host *.yahoo.com matches no real domain, and this entry has no real effect at all on your permissions. I've seen many people do this; I think it's a common misunderstanding. Yes, this is user error. But it seems to me we should account for it. Many people have studiously entered host permissions that have no effect, and give no direct indication of their lack of efficacy. Mozillazine forum complaints of Yahoo Mail objecting that Firefox doesn't accept cookies are not uncommon. I wonder how many of those are because of this misunderstanding? I see two choices: immediately strip off any leading *. entered in the dialog, or store it with the pointless wildcard but strip it off when building the hash table. I think the former would be initially bewildering, but also less misleading. After all, keeping and displaying the leading *. incorrectly implies that (*.yahoo.com and yahoo.com) are different. Most users knowledgeable enough to add the *. are knowledgeable enough to figure out what it means when we keep dropping it. I lean toward stripping off the leading *. immediately. (We might also do both, thereby correcting legacy users' permissions files.)
Agreed. We could also add text in the permissions window to the effect of wildcards being useless. One sentence should do the trick. I hope at least our help docs explain it...
Or we could complain on invalid hostnames (which this is, no?) and suggest to the user that if they're trying to have a domain and all subdomains whitelisted they should just whitelist the domain.... (this last clause shows why I don't design UI, eh? ;) )
No. If the user is using a wildcard, their intention is pretty clear, we should just do it, and _possibly_ include a sentence explaining it. I'm not even sure if we need to go that far, since users actually adding exceptions are almost by definition saavy enough to understand after the first time.
OK, I'll buy that for wildcards. I still think that after wildcard-stripping we could use hostname-validity checking... but I guess that's food for another bug. ;)
http://lxr.mozilla.org/mozilla/source/browser/components/preferences/permissions.js#106 that's where the wildcard stripping needs to go.
How do you validate a hostname? You should be careful about making assumptions about what the hostname of a URL looks like. It may not be a name that is resolved using DNS.
We've dealt with a lot of these issues in "No Proxy For" already. In short, the back-end filtering does not use strings with a leading "*". However, the front end allows it, and the "*" is removed when the pref string is parsed into an array. I think you want a front-end that allows users to enter something sensible, but then do some minor fix-ups to store the values in a way that makes sense. I would prefer that the users enter a domain string, and be given a menu/radio selector that says: [hostname-only | domain-only | domain & sub-domains]. FQDN validation can be done, I wrote a JS function that does it, but in some places, like this, it might be better to let people enter whatever they want. Sometimes the OS allows things to slip through that don't make a lot of sense.