image blocking info is currently saved to a file called cookperm.txt. Not a very good name.
It's an internal name only and not worth fixing. If we had to worry about internal names, then we'd have to be concerned about localizing them also. I'm marking this wont-fix but if you object to that then reopen and I'll mark it future.
It's not an internal name; it appears at the top level of the profile folder. If the name is important, it should be called `Cookie & Image Permissions'. If the name is not important, it should be called `123goat'. Either way, the current name needs improving. :-)
The images permissions are currently mixed with the cookies permission in the same file. I think it is not a good idea as long as we may want to block a _part_ of url for images (like */ads/*) while it is only domain-related for cookies. Shouldn't bug 78104 be marked as depending on this one?
The new popup manager also uses this file for it's popup blocked sites. Now we have three different functions (or we will, once the popup manager is hooked up again) using the same file. If all three are to use the same file, and it's to be renamed, it should be named simply "permissions.txt". If it has to stay as an 8 character name (?) then simply perm.txt.
over to mvl, please fix or wontfix as you see fit.
I think it doesn't really matter how the file is named. It would be slightly better is it had another name, but it would cause to much paint to get the compatibilty with older profiles done right. So leaving this open, but as enhancement.
The comment at top calls it "HTTP Permission File" but now even that isn't true. JS popups aren't a part of HTTP. I'd suggest siteperm.txt, since it deals with permissions for individual sites. It'd be ideal if there was some way to change this. New profiles make a file named that, and the loading code, at least until 1.0, loads siteperm first, and if that fails, then tries cookperm. Also, the "# http://www.netscape.com/newsref/std/cookie_spec.html" line should definately be removed. The cookie spec is unhelpful, and now, irrelevant.
I agree on the comments on top of the file, they don't really make sense. But what would renaming the file bring us? A regular user never sees the file, and it will only cause extra code and possible bugs. So i don't really see the need.
wontfixing, since this isn't worth the pain. we can rename it for mozilla 2.0.
> we can rename it for mozilla 2.0. In which case, WONTFIX is the wrong resolution.
Reassigning to nobody, leaving open with target date of future. If it won't *ever* be fixed, then you can WONTFIX it again.
I argue that we ought not to fix it. Correct the comment at the top of the file and if you want add a note that the filename is "historical", but otherwise renaming the file is just not worth the work or the code bloat (bloat comes from the need to deal with existing data saved under the current name). If anyone's got spare time we've got literally thousands of more important bugs to work on.
Fixed by bug 219752 :D hostperm.1 is the new name.