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

UNCONFIRMED
Unassigned

Status

()

Core
Networking: Cookies
--
major
UNCONFIRMED
9 years ago
a year ago

People

(Reporter: HeX, Unassigned)

Tracking

1.9.2 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-would-take])

(Reporter)

Description

9 years ago
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

Updated

9 years ago
Duplicate of this bug: 434710

Comment 2

9 years ago
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

9 years ago
(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.
(Reporter)

Comment 4

9 years ago
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

9 years ago
The workaround on comment #4 does not work on Windows.

I confirm this bug on FF 3.0.3 on Windows.
(Reporter)

Comment 6

8 years ago
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

8 years ago
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
Whiteboard: [CLOSEME 2010-09-15]
Version: unspecified → 2.0 Branch
(Reporter)

Comment 9

7 years ago
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.
Whiteboard: [CLOSEME 2010-09-15]
Version: 2.0 Branch → 3.6 Branch

Comment 10

7 years ago
FF 4.0 beta 6 presents still the same behavior.

Comment 11

6 years ago
I confirm this bug in FF 4.0b12 on Windows XP.
(Reporter)

Comment 12

6 years ago
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

6 years ago
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.

Updated

4 years ago
Component: General → Networking: Cookies
Product: Firefox → Core
Version: 3.6 Branch → 1.9.2 Branch
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.