Last Comment Bug 430045 - Can not add a permanent cookie exception for file:// locations
: Can not add a permanent cookie exception for file:// locations
Status: UNCONFIRMED
[necko-would-take]
:
Product: Core
Classification: Components
Component: Networking: Cookies (show other bugs)
: 1.9.2 Branch
: x86 Linux
: -- major with 19 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 434710 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-21 05:58 PDT by HeX
Modified: 2016-02-02 12:58 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description HeX 2008-04-21 05:58:16 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; nb-NO; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11 Mnenhy/0.7.5.666
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; nb-NO; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11 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
Comment 1 Daniel Thompson 2008-05-20 04:35:00 PDT
*** Bug 434710 has been marked as a duplicate of this bug. ***
Comment 2 David Kleppinger 2008-06-22 14:13:37 PDT
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.
Comment 3 Daniel Thompson 2008-06-30 03:03:33 PDT
(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.
Comment 4 HeX 2008-08-04 02:28:54 PDT
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
Comment 5 Flavien Scheurer 2008-11-06 04:22:30 PST
The workaround on comment #4 does not work on Windows.

I confirm this bug on FF 3.0.3 on Windows.
Comment 6 HeX 2009-06-14 04:01:00 PDT
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 :(
Comment 7 John Rouillard 2009-09-11 14:07:21 PDT
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
Comment 8 Tyler Downer [:Tyler] 2010-08-27 11:59:13 PDT
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
Comment 9 HeX 2010-08-28 08:56:32 PDT
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.
Comment 10 George Billios 2010-10-25 11:10:40 PDT
FF 4.0 beta 6 presents still the same behavior.
Comment 11 Thomas Henlich 2011-03-08 07:00:30 PST
I confirm this bug in FF 4.0b12 on Windows XP.
Comment 12 HeX 2011-03-08 15:47:29 PST
Just to confirm for the 3.x series. It's still present in:
Mozilla/5.0 (X11; U; Linux i686; nb-NO; rv:1.9.2.15) Gecko/20110303 Ubuntu/10.10 (maverick) Firefox/3.6.15 ID:20110303171539

PS: What does it actually need to raise this to "confirmed"?
Comment 13 Thomas Henlich 2011-03-12 04:35:47 PST
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.

Note You need to log in before you can comment on or make changes to this bug.