User-Agent: Mozilla/5.0 (X11; U; Linux i686; nb-NO; rv:220.127.116.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/18.104.22.168 Mnenhy/0.7.5.666 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; nb-NO; rv:22.214.171.124) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/126.96.36.199 Mnenhy/0.7.5.666 In FF2 it was possible to store an exception for cookies to be stored permanently for 'file://' locations. This is quite vital for the use of tools like TiddlyWiki (www.tiddlywiki.com). In FF3b5 it is plainly not possible to store such an exception since only the remainder of the URI (without http:// or file://) is stored in the sqlite database. Reproducible: Always Steps to Reproduce: 1. Set FF to ask every time if a site wants to set or change a cookie 2. Open a TiddlyWiki file an change something (e.g. a tag, Username) 3. Window pops up and asks if the cookie should be allowed for 'file://' 4. click accept permanently Actual Results: Next time something is changed the Window for asking about how to handle cookies from 'file://' locations pops up again. Expected Results: There should be no additional questioning pop up window as we already allowed the cookies from file:// to be stored permanently When looking a the sqlite database for cookie exceptions there is no field present for the file:// locations
This also applies to all the html format ebooks that are downloaded from http://www.webscription.net (try the free library for an example). This makes it a major annoyance for me.
(In reply to comment #2) > This makes it a major annoyance for me. I must confess I concluded that I would have to trade a (small) amount of privacy for convenience in order to workaround this bug. I've simply configured FF to always accept cookies but to treat them as session only cookies.
Good news, at least for TiddlyWiki files (www.tiddlywiki.com). There is now a clean workaround available: http://www.tiddlywiki.org/wiki/Firefox_3#Cookies
The workaround on comment #4 does not work on Windows. I confirm this bug on FF 3.0.3 on Windows.
Bad news, with the latest FF version 3.0.11 and probably because of the fix of bug #491801 the workaround with file://localhost/ URIs is not working anymore :(
See also: https://bugzilla.mozilla.org/show_bug.cgi?id=440973 The problem is also present when using the ask me about accepting cookies functionality. The inability to set an an exception means every cookie based operation, changing tabs, changing options etc pops up a dialog. -- rouilj
Reporter, are you still seeing this issue with Firefox 3.6.x or later in safe mode? If not, please close. These links can help you in your testing. http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/kb/Managing+profiles
This problem still persists in FF 3.6.8. Wouldn't it be possible to store the exceptions including the file:// or http:// or https:// bit in front of it.
FF 4.0 beta 6 presents still the same behavior.
I confirm this bug in FF 4.0b12 on Windows XP.
Just to confirm for the 3.x series. It's still present in: Mozilla/5.0 (X11; U; Linux i686; nb-NO; rv:188.8.131.52) Gecko/20110303 Ubuntu/10.10 (maverick) Firefox/3.6.15 ID:20110303171539 PS: What does it actually need to raise this to "confirmed"?
I propose that the hostname "localhost" be used to apply cookie settings to file:// URIs. This would be in concordance with RFC 1600 which states: A void host field is equivalent to "localhost". and RFC 1738: As a special case, <host> can be the string "localhost" or the empty string; this is interpreted as `the machine from which the URL is being interpreted'. The drawback would be that this setting would also apply to http://localhost/ URIs, but this is probably acceptable.