430045 - Can not add a permanent cookie exception for file:// locations

Status: RESOLVED INVALID

(Core :: Networking: Cookies, defect, P5)

Description

[HeX]

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 2

[David Kleppinger]

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]

(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]

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]

The workaround on comment #4 does not work on Windows.

I confirm this bug on FF 3.0.3 on Windows.

Comment 6

[HeX]

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]

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 [He/Him]]

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]

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]

FF 4.0 beta 6 presents still the same behavior.

Comment 11

[Thomas Henlich]

I confirm this bug in FF 4.0b12 on Windows XP.

Comment 12

[HeX]

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]

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.

Comment 14

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 15

[Andrea Marchesini [:baku]]

This bug is not valid. Storing cookies do not require user interaction.
Plus, file: URLs are now unique origins, and because of this, running a webapp using file: URLs and cookies is particularly hard and not recommended.