New issue
Advanced search Search tips
Starred by 57 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2008
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

  • Only users with Commit permission may comment.

Sign in to add a comment

Issue 535: Support cookies on file://

Reported by, Sep 3 2008

Issue description

Product Version      : (1583)
URLs (if applicable) :
Other browsers tested:
     Safari 3: OK
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. download TiddlyWiki (right-click and save as:
2. open TiddlyWiki from local file
3. assign username in GettingStarted
4. close TiddlyWiki tab
5. re-open TiddlyWiki

What is the expected result?
The previously entered username should be filled in automatically.

What happens instead?
The previously entered username has not have been saved (in a cookie).

Comment 1 Deleted

Comment 2 by, Sep 3 2008

Minimal testcase attached.

What is the expected result?
Should report "2 cookies found".

What happens instead?
Reports "no cookies found"
679 bytes View Download

Comment 3 by, Sep 3 2008

Labels: -Type-Bug Type-Feature
Summary: Support cookies on file://
Chrome intentionally disables cookies on file://, for a variety of reasons.  When we 
wrote our cookie support, the correct behavior was unclear when dealing with things 
like file shares.  We found cookies on file:// to be fairly uncommon, and it has a 
few negative security implications.

You can, however, enable them with the command line flag --enable-file-cookies.

I will change this to a feature request for supporting file:// cookies.

Comment 4 by, Sep 6 2008

Dean, is there a reason why we'd want this feature request if we've intentionally 
disabled them?

Comment 5 by, Sep 6 2008

Status: WontFix
OK, marking as WontFix.  People can still comment on the bug if they feel it's 
important, and we can always revisit later on.

Comment 6 by, Sep 6 2008

All of the resources at my site are in TiddlyWiki format. I
also use TiddlyWikis for daily productivity and note-taking. As do many, many people.
Everyone is pretty excited about Chrome, and would like to see TiddlyWiki work on
Chrome. But if you mark it as WontFix, all of us TiddlyWiki users will have to stick
with Firefox. Sorry.

Dave Gifford

Comment 7 by, Sep 6 2008

Cookies are *strictly* a HTTP mechanism as per RFC 2109. There should be no
reasonable expectation for them to work for protocols other than HTTP, much less
file:///, and it is not clear what their behavior should be, and what rules of
security compartmentalization should apply.

Some example questions: should cookies for file:///c:/foo/ be shared with
file:///c:/bar/? what about cookies for file://otherhost/baz? should cookies from be shared with what about HTML files downloaded
to local disk from the Internet, should they keep their original context, or intrude
that of any HTML code installed locally? Lacking clear and consciously defined rules,
this is a ticking time bomb.

Historically, various browsers followed somewhat inconsistent rules in this
department, mostly out of oversight. Most of these mechanisms have undesirable
security consequences, too. A very small fraction of applications took the
availability of file:// or ftp:// or SMB/NFS cookies for granted and started to rely
on this undocumented mechanism for unusual applications. I would be willing to pretty
strongly assert that this is a failing on the side of the application, not a
particular browser.

Comment 8 by Deleted ...@, Sep 7 2008

There's an emergent class of applications, which includes TiddlyWiki, Desktop widgets and HTML Applications (HTAs)  for which 
storing cookies for a file URI is extremely useful for maintaining context, such as the wiki author and preferences, across 
browser sessions. 

Whilst I'm impressed the development team are cautions in opening up "undocumented" features which have a security impact, 
Chrome is currently the only major browser not supporting cookies for file URIs, rendering it unusable for a number of existing, 
often innovative, web applications. This is a shame, because it looks very promising, and would otherwise be a browser I'd 
advocate people to switch to.

Restricting the scope of a stored cookies to the single file URI which created them, is perfectly acceptable for the TiddlyWiki 
usecase, and a simply implemented rule. 

In addition, most browsers issue a challenge when opening a file URI for the first time, warning the user using language similar 
to downloading an application.

Comment 9 by, Sep 7 2008


As I had previous stated, for the people who really do want cookies on file:// 
protocols, you can run Chromium with the --enable-file-cookies command line flag.

Comment 10 by, Sep 7 2008

Comment 11 by, Sep 7 2008

> for the people who really do want cookies on file:// protocols,
> you can run Chromium with the --enable-file-cookies command line flag

Would it not make sense then to turn this into a setting accessible via the UI? The
"Under the Hood" options tab seems like the perfect place.

Comment 12 by, Sep 7 2008

This is something that a very very small percent of users will want.  In fact, I do 
not encourage this at all, because we intentionally don't allow cookies on file:// 
over security concerns.  I would not want this as a preference as it allows the user 
to make their browser less secure.  If you want to modify your source and build your 
own Chromium, or to run with a non-recommended command line flag, then you're surfing 
at your own risk.

Comment 13 by, Sep 8 2008

Restricting cookies to a specific file or path doesn't address the security concern
because it creates a finer-grained origin (see

Comment 14 by Deleted ...@, Sep 19 2008

I won't use Chromium (as I do nowadays) if I can't use TiddlyWiki!

Comment 15 by, Nov 3 2008

I must not be understanding the reasoning here.  My application runs both on-line and 
off-line, not a very unusual feature for a statistical calculator.  It saves language 
choice and other preferences in a cookie, which works very well in both IE and FF.  
In Chrome, it fails to save to the cookie, giving no indication of what is happening, 
so that I have spent days debugging trying to make it work.  Now I find that the user 
should only run Chrome with a special command-line parameter that not one in a 
thousand would figure out how to insert.  Is this really what you want Chrome to do? 

I wouldn't mind inserting something in my Javascript to allow cookies (how about 
document.cookie = "my settings"), or limiting what I write to the cookie, but right 
now, it seems the only option is to tell people never to use Google Chrome to run 
OpenEpi off-line.  This is a real shame because we hope to use Google Gears later on 
for the very purpose of enhancing off-line use.

Comment 16 by Deleted ...@, Dec 20 2008

I wont use Chrome if I cant use Tiddlywiki ALSO

Comment 17 by Deleted ...@, Jan 19 2009

By not allowing local file:/// cookies, you are preventing all current web 
applications that are used offline from saving/persisting user-data. Local cookie 
storage is the universally accepted method (as in all other browsers) for saving 
user data, and is a cross-browser solution. Security is not the issue here, as any 
offline web-application can store and retrieve information via an online server. So, 
the only reason i can see, is that this is to promote google gears only - I really 
hope this is not the case, as Chrome is a fantastic browser. Please support current 
web-applications, by allowing local cookies - it's essential for them to be able to 
store user settings etc.

Comment 18 by Deleted ...@, Feb 10 2009

FWIW: I am developing a web application which runs locally and uses cookies to save 
state.  It runs in FF, Safari, IE, but NOT Google Chrome!!!

Sorry if this is a "Me too!" but, Can someone post instructions on how to set the --
enable-file-cookies flag -- And can this be done from within Javascript??


Comment 19 by, Feb 25 2009

Safari allows access only to local cookies which were recorded in the same folder or in the parent 

Parent folders can't access cookies, stored in child folders

firefox uses the same behavior.

It seems good behavior, at least all browsers use this defacto

Comment 20 by Deleted ...@, Mar 6 2009

A shame TiddlyWiki doesn't work properly under Google Chrome when it does under every 

Comment 21 by, Apr 23 2009

I hate to point out the obvious, but the eggheads at Google apparently have never
developed web pages of their own offline before uploading them to a server.  Testing
before going live is, as we all know, generally a good thing.

How are millions of web developers around the world supposed to test their new
cookie-utilizing web apps (developed offline) against Google Chrome... except once
they have gone live?  They can test their new creations offline with basically all
other browsers... just not Chrome.

Writers of Chrome -- did you test the Chrome browser internally before you released
it?  What if you hadn't?  See my point?

The responses I am seeing from appear to be a cop-out... the other major
browsers work just fine offline, without the perceived problems outlined above.  I
can code a web page, test it (including the cookie aspects) and then upload it to my
server with the full confidence that it will work online if it works offline.

But... not with Chrome.

Comment 22 by Deleted ...@, Apr 27 2009

Developing & testing javascripts that use cookies without this ability is also a 
pain.  I have been trying (for days now) to figure out why "local session cookies" 
were failing on Chrome.  Then, I found this thread...

Comment 23 by, Apr 27 2009

As discussed earlier, for local development, cookies in file:// might be enabled from
command line with --enable-file-cookies.

Comment 24 by, Apr 28 2009

Thank you lcamtuf, we are aware of that, but that's kind of like saying "In order to 
view this new house I built for you, we need to come in through the chimney as there 
is no front door yet".

I don't know about most developers, but when I test a web page in a browser I double-
click on its HTML file.  I don't start messing around with command lines and then 
manually typing the address of the test page into the address bar or navigating 
various levels of directories to locate the page.

It is and always has been a basic, fundamental feature of any browser that you could 
open up a web page on your local machine with full HTML functionality by simply 
double-clicking it, just like any other file.

But not with Chrome.

This is am important feature that should be selectable on a permanent basis from a 
menu in the browser.  All the work has been done!  The browser can do it!  All we are 
asking for is an easy way to set it up permanently.

It seems to me like Google is trying to be a "nanny company" here, kind of like AOL, 
"protecting" its innocent users from the evils of "dangerous things"!

AOL: "Don't click on hyperlinks... they might contain a virus... we'll disable them 
in emails for you."

Google: "Cookies are very dangerous for your health.  We don't think you should use 
them unless you are an expert who knows all about command lines."

Comment 25 by, May 16 2009

In the absence of a reasonable response to this issue, can you recommend some other 
way of storing, say, a language preference, for an offline/online app that does not 
use Gears?  As soon as the user downloads my HTML/JS  to local disk, there is no more 
Spanish or Italian translation because it can't read or store two characters in 
document.cookie.  Everything else works well, and it is ONLY Chrome that fails.  
Please tell us (the "small percentage of users") how to save and read the tidbits 
that normally belong in cookies when our users are out of Internet contact.

Comment 26 by, Jul 21 2009

Please can anyone help me. I now have Google Chrome and love it. I am a Realtor and 
use it for property searches. Whenever I enter a multiple listing number to view the 
homes media/pictures i get pop up blocked. Most of the ones I have used in the past 
allow me to turn off the blocker for this site but cannot find it for the Chrome. My 
Realtracs support tells me that for this reason I cannot use Chrome. (I need to allow 
pop ups for this site) I love Chrome in so many ways and am devistated to leave it. Is 
there another way?  Realtor Boyd

Comment 27 by Deleted ...@, Jul 27 2009

It is not really true that cookies for file:// protocol "is something that a very 
very small percent of users will want". The fact that there are not many many 
comments from people asking for this feature (in Chrome) is that Chrome is not still 
as popular as IE or Firefox, for example. And the people who are writing these 
comments as I can imagine, are developers, testers or technical involved people, who 
wants Chrome to be as competitive as others. If Chrome fails to offer cookies under 
file: protocol, many people like us will fail to popularize Chrome among our final 
user: our final products should have a notice like "Requirements: All browsers BUT 
Google Chrome". 

In spite that by definition Cookies are *strictly* a HTTP mechanism (as per RFC 
2109), there is not reason for not providing a friendly way (at least for 
programmers, for example a javascript code or an html meta) that allow a cross-
compatibility among the most popular browsers at this respect, including the nascent 

Comment 28 by Deleted ...@, Aug 27 2009

There will always be a better way to solve the problem than simply deny cookies: you 
can restrict some behaviors to avoid security problems. Flash Player restricts their 
behavior to avoid cross-domain access when running on local machine. The same with 
JavaScript, every AJAX developer knows that there are a couple of local runing 
restrictions, but of course, restricted behavior is preferable to none at all.

I'm working on a local page what will be published on DVD, it needs cookies to work 
so I have two choices: to warn the user to use every browser but Chrome, or recode 
the project to send every var in the querystring of every link to make it 
Chromium/Chrome compatible.

With these premises: ...

1. Cookies are not malware, virus or sent from hell. In fact they are necessary in a 
lot of local projects.
2. The developer community is calling for a solution.
3. Chromium/Chrome is the only one who has taken that step.

...what would you choose in my place?

Comment 29 by Deleted ...@, Sep 21 2009

I am using chrome for quite some time now, and I recently began creating a video
browsing application based on javascript that would be for offline use only 
( kind of like a dvd with your favourite show videos, and the html used to select the
video you want to play ), anyway, after many hours I reached to a point where I would
use cookies to store/restore some data. 

Well.. you guessed it. At that point I was going apecrazy and started to check my
code again and again to see what was wrong. It was only when I tested the page with
opera that I thought something is not right..

Chrome is intentionally denying offline cookies !!

You really should enable this feature, or AT LEAST give the ability to users to
enable it by menu or something.

Something like going to ?"about:cookies"?  and then 
checking the option : "Yes, please do enable offline cookies and by checking this I
realise that I may be putting my computer in danger" or something like that.

And then click on that, click save, and there you go.
everyone is happy.

( the --enable-file-cookies won't work for my friends, who are not computer experts )

Comment 30 by Deleted ...@, Sep 24 2009

ARGHHH:  two hours wasted trying to figure this out. I understand the rationale but
the statement "only a small percentage of applications would want this" is way off
the mark!

Comment 31 by, Oct 2 2009

@diagnose - "I don't know about most developers, but when I test a web page in a
browser I double-click on its HTML file."

If you are creating web sites with HTML only, you are in the minority. Most web
developers are using some kind of server-side processing (PHP, Rails, Django,
ASP.NET) so that the site can use a database, or, at the very least, not repeat menu
code in every file (for example, see this tutorial on PHP's include command - In that case, we run a web server on our
local machine for testing purposes. The address of the page would then start with
http://localhost instead of file://.

@everyone else: does opening the page from http://localhost solve the problem?

Comment 32 by, Oct 2 2009

> does opening the page from http://localhost solve the problem?

While I haven't tested this, I assume it would - however, the requirement to have a
local web server (for HTTP) is contrary to TiddlyWiki's self-contained single-file

FWIW, Firefox supports file://localhost/path/to/local/file:

Comment 33 by Deleted ...@, Dec 18 2009

In order to be able to use local cookies, I've been starting Chrome with --enable-file-
cookies in the command line.  Awkward, and annoying, but it has worked.  However, lately 
even that doesn't work.  Has Chrome changed its policy, or does this indicate a problem 
on my machine in particular?

Comment 34 by, Dec 18 2009

Works for me in; if it stopped working for you in some particular version,
sounds like a bug.

Comment 35 by Deleted ...@, Dec 20 2009

The version I'm using under XP, in which the flag doesn't work, is, which 
"About Google Chrome" says is up to date.

Comment 36 by Deleted ...@, Dec 25 2009

I'm on ubuntu and using Chromium (35262). The command --enable-file-cookies 
does not work for me too. TiddlyWiki would not save when opened in chromium.

Comment 37 by Deleted ...@, Dec 28 2009

Not working for me in Chrome version on Vista.  Started Chrome with --
enable-file-cookies but cookies are not being set when testing my page locally.

Comment 38 by Deleted ...@, Jan 8 2010

Still --enable-file-cookies not working in Chrome (Linux).

Comment 39 Deleted

Comment 40 by Deleted ...@, Jan 18 2010

--enable-file-cookies not working in Chrome (Windows 7).

Comment 41 by Deleted ...@, Jan 22 2010

... --enable-file-cookies works in Chrome, Windows 7!

Comment 42 by, Jan 22 2010

--enable-file-cookies not working in Chrome (Windows 7)

Comment 43 by Deleted ...@, Jan 23 2010

--enable-file-cookies is not working in Chrome on Windows XP pro 5.1

Comment 44 by Deleted ...@, Jan 26 2010

--enable-filecookies is not working in Chrome (36714) on Windows XP pro 5.1

Comment 45 by Deleted ...@, Jan 26 2010

Just saw  issue 17790 . Thought20 commented "If there are NO OTHER CHROME 
INSTANCES running on the machine, starting Chrome with --enable-file-cookies works.
If there are any instances already running that were NOT started with
--enable-file-cookies, any launch of a new Chrome instance will ignore this flag."
Ah hah. Retested and --enable-file-cookies works in Chrome (36714)
on Windows XP pro 5.1

Comment 46 by, Jan 26 2010

--enable-file-cookies not working in Chrome 4.0.302.3 (Windows 7)

Comment 47 by, Jan 27 2010

As commentor #45 cynthia.rayl/Thought20 pointed out this appears to be the case for 
Chrome 4.0.302.3 on Win 7. If you've setup an application shortcut and have that open 
first --enable-file-cookies will not work. I believe you can add the --enable-file-
cookies to all your Chrome application shortcuts and you should be fine.

But this work around is stupid. I rely heavily on tiddlywiki. Please allow file cookies 
on Chrome Google!

Comment 48 by, Mar 8 2010

This issue is also discussed at

And I just posted this comment there.

A strange thing happened yesterday in that I thought about how Google Chrome won't
use local cookies and then two posts were made to the thread.

I decided to try it again (it did not work for me last April when I tried) since more
people have said that adding <<--enable-file-cookies>> into the command line does work.

Chrome requires one other change -- in the cookie options one must select <<Allow all
cookies>> rather than <<Accept cookies only from sites I visit>>.  Apparently a local
file is not considered a "site that I visit".  So, either I have keep switching back
and forth or always accept third party cookies.

Incidentally, Chrome reports 'cookie written' even when it does not rather than
report a failure to write a cookie.

Obviously, Google is infected with the NIH virus. <sigh>

I will also add that the command line thing can be put into the shortcut so that it
is automatic.

Comment 49 by, Mar 12 2010

Hi, as a developer I have to note it is better to restrict users in a small way (it's 
not that hard to set the --enable-file-cookies flag to your shortcuts and default 
double-click open functionality) than to making then vulnerable to cross site 
I do however do not like that you do not get any notification of this. I therefore 
would like to suggest this change request: When a file wants to store cookies when it 
has no permissions (file:///) to present the user with a pop-up with an explanation of 
why it will not work and how to work around it (including the risks).

Comment 50 by, Apr 15 2010

I am developing a help doc, and i wanted users to have *sticky* settings, like code language.  so that if a user 
selects javascript on one page, then they get the help docs on the next page in javascript.

if the only way to store state it in the url, that sucks.

i guess i could, force rewrite all links in a page with a #javascript hash or something in jQuery, but a cookie 
would have been simple.

Comment 51 by, Apr 18 2010

has anyone tried using HTML5 features to work around this?  webstorage might work.

i was also thinking of storing this in the #hash tag, however that is really limiting and hard to carry over from 
page to page.

what other ways are there to store info in a browser durring a session?  flash cookies?

whenever a browser has unexpected behavior like this, i feel like there is always a work around that comes about.

Comment 52 by Deleted ...@, May 27 2010

@google - please link me to an html document that i can save to my desktop and run in 
IE and/or FF compromising my machine with file:// cookies.

until you can either provide an example of a security hole or implement file:// cookies 
the way FF and IE do then my chrome browser will continue to gather dust.

(what was that about google being open and inclusive unlike apple?)

Comment 53 by, May 28 2010

@ctrpapa: I don't want to create the document, but imagine the following:
1) I create a html page with javascript that reads all your cookies and posts that 
info to my server (using ajax for example).
2) I host this page on a network share, publicly available to anyone.
3) I send you the link of this network shared file and you either open it directly or 
download it to your disk and open it there.
4) Since networkshares and localhost all have the same accessability level, I now 
have all data you have ever stored using similar files.
So if you have every stored your credentials in a cookie in a 'safe' file on your 
desktop, you are screwed. Less critical information can also provide me with an entry 
to your system.

Comment 54 by Deleted ...@, Jun 30 2010

I am one of the developers of the C++ source code documentatiob tool DoxyS ( which generates HTML code intended very much for local viewing too. 

We also have problem with Chrome :-(

Comment 55 by, Jul 4 2010

I haven't tested this, but if there's a one-file webapp on linux,
while true; do nc -l 49152 < "$1:-/dev/null"; done & google-chrome http://localhost:49152/
can be saved in an executable text file
drag files into it to execute
Put a pair of brackets around the loop and an ampersand after to keep it alive even after chrome exits

If multi-file support is necessary, you can write a script that uses nc to only listen to localhost, and uses sed to parse the header, although you may as well:
mount ~/web-testing /var/www/html/testing -o bind
And disable selinux

Windows: you can install cygwin (first suggestion), or apache (second)

fine print:
I have tested none of this. If you follow any of these instructions, you may become vulnerable
to velociraptor attacks and other nasty things.

Comment 56 by Deleted ...@, Aug 12 2010 wrote:

This is something that a very very small percent of users will want.  In fact, I do 
not encourage this at all, because we intentionally don't allow cookies on file:// 
over security concerns.  I would not want this as a preference as it allows the user 
to make their browser less secure.  If you want to modify your source and build your 
own Chromium, or to run with a non-recommended command line flag, then you're surfing 
at your own risk.

Then add this function in "Options" menu (like pop-up that are disabled by default) with "suggested" choice enabled, and give to the user the possibility to change it.

Comment 57 by, Aug 12 2010

deanm wrote "I would not want this as a preference as it allows the user 
to make their browser less secure."
So probably you can stop hoping to get this as a user option. Instead look at HTML5 offline functionality and bind your stored data to a website hostname. The local helpfile.htm use case seems it's getting thrown out completely though.

Comment 58 by, Aug 27 2010

I've problem with some app intended for local use only, where pages must know some data from pages previously visited. Why Chrome sets itself as default application for opening HTML files at all if it makes HTML application not functional? Maybe denying users at all to open HTML files without a webserver will be better? At least it won't make users confused why app that should work does not.

Comment 59 by, Sep 12 2010

There is a striking resemblance here with this issue:

Comment 60 by Deleted ...@, Sep 18 2010

It's crazy that this isn't enabled by default.  On OSX, it's a bit more challenging to add a command line switch to an app.  Here's the best writeup I've found:
(substitute the command line switch described for --enable-file-cookies of course)

There's no way I'd walk a novice through this.  For the novice's I know, I could just send them an updated app.

To the security argument: restricting cookies to the full URI (including the file name) should negate any of the security issues and allow most, if not all of the mentioned apps to function properly.

Comment 61 by, Sep 18 2010

Who uses Chrome on MacOSX where there are already native Safari webbrowser which uses same rendering engine (WebKit)?

Comment 62 by Deleted ...@, Sep 29 2010

I too feel this is ridiculous! I develop many things locally and have been banging my head  until I read this thread! It should be an option I can enable. How is that making Chrome unsecure, if I know the risks involved. Seems to me you are cutting off your nose to spite your face!

Comment 63 by Deleted ...@, Oct 5 2010

I just downloaded Google Chrome to see what my website looks like on it, not knowing that the JS and Jquery would not work locally on my computer. I'm not bothered about all the reasons for this and I am not even going to try to fix it.  So I am now going to discard and forget all about Google Chrome.
Thank heaven for Firefox.

Comment 64 by Deleted ...@, Oct 7 2010

thank heaven for firefox indeed, it took me a couple of hours to figure out that chrome wasn't saving local cookies... quite annoying that there was absolutely no notification or errors in the JS console when trying to set a cookie through JS.

you can make the argument that cookies are an HTTP protocol spec - and I would say that  chrome should disable cookies in JS completely then, because that's not coming through the HTTP headers...

I think it's silly that at the very least there is no notification that local cookies are not being stored, or that there is no easy configuration switch to enable this functionality... you are forced to use a command line switch....

Comment 65 by Deleted ...@, Mar 10 2011

Status : Wontfix 

Does any one at Google has some idea, about time that a small developer wastes because their browser does not behave like most other browsers on the issue.
and then we condemn Microsoft for being insensitive to public requests. Google is a quick learner indeed.

Comment 66 by, Mar 10 2011

I just tell my clients they must use Firefox, and avoid Chrome and IE. Problem solved, I guess?

Comment 67 by, Mar 10 2011

It seems to me that Firefox has also stopped supporting cookies on file:// -- or is it just me?  What a lame reason by Google techs here: "Security Reasons".  LOL!  Protect myself from myself?

Comment 68 by Deleted ...@, Mar 18 2011

This is disappointing, i've been striving for compliance across all major browsers in all my products, however, when my web dev server temporarily breaks down, i'm left to use a local machine with local files... i have xammp installed for quick http:// stuff, but if i am playing around with CSS and Styles that require my javascript implementations... (mainly i use cookies for remembering your accesibility options to apply to domain wide pages) however since my remote server went down, and i did all my dev work on chrome, in the first iteration anyway. Testing on chrome suddenly wasted a lot of hours on bug finding in my code, failed unit tests in chrome only.. Even IE works..  and i thought IE was the 'hard part' in web dev.. no longer will i be switching from firefox to chrome, for primary development.  Or as a primary browser.. Chrome team, probably don't care too much about the small amount of marketshare they might lose from developers like us in this thread.. but thats why firefox rules..

Comment 69 by Deleted ...@, Jul 18 2011

3 years later and this is still causing developers wasted hours. Me too. Some sensible suggestions on a warning that cookies aren't being stored by JavaScript are being ignored.
Concentration of power and arrogance, the "axis of evil" starts with Murdoch, Gates, Republican Party, and now Google has joined.
I've told you a million times I don't exaggerate.

I'm also having difficulty with Chrome on live websites using JavaScript to write session cookies. Am I going to spend any more time on it when it even works in IE? You know the answer.

FireFox is best, first because it works well and quickly, but secondly because it doesn't actually need the JavaScript I've written - it remembers the scroll position of my <div> when browsing back to a page.

Comment 70 by, Jul 18 2011

This was a major frustration to me too.  The answer for me was to use HTML5's Local Storage [1].  I was only using cookies to retain (client side) user configuration on whether components on my pages were 'on' or 'off'.  Therefore Local Storage was a perfect alternative to me for cookies.

Hope this helps.


Comment 71 Deleted

Comment 72 by, Jul 31 2011

I'd like to know if anyone has an attack scenario where the origin of the file setting the cookie is important. The only attack scenarios mentioned in the thread are just as viable when committed through a hosted application. I think the author of the last scenario was thinking of the javascript in cookie attack which is very different.

Turning cookies on for file:/// should definitely be a setting.

Localhost doesn't work because you have to have web server running.
If you hack python you can write a lightweight one really fast and then you can get to your local files via http://localhost/..

Keep in mind that this potentially makes all of your files visible on the web. Make sure that your firewall / router are providing the necessary protection.
Note that this is much more dangerous than enabling the file:/// cookies. And it won't help you with setting cookies from javascript. Getting the simple server to parse javascript is not so simple. The other alternative is to install Apache or other proper webserver on your machine and begin the arduous task of making a proper webserver. And remember to make it only accessible from your local machine.


Comment 73 by Deleted ...@, Aug 2 2011

I use Chrome like I used the last version of Netscape - simply as a nice clean fast webmail client for GoogleMail and Yahoo, with nothing in bookmarks.
I just don't use it for browsing the web.
I tell everyone I know, or web design for, to use Opera or FireFox; not to be surprised if Chrome behaves oddly, and to strenuously avoid IE.

Comment 74 by Deleted ...@, Aug 24 2011

3 years and still "Wont Fix". This is ridiculous. As some fellows here I have wasted valuable time on this bugger. Time I don't get paid for...

I would except that kind of behaviour from IE. That's one reason why test my designs in IE from a dropbox public folder. I have to do that too in chrome now. Pity.

If you really can't fix this, at least bother to give SOMEWHERE some FEEDBACK. use a popup, or let the Chrome developer tools shed some light on the root of this problem.


Comment 75 by Deleted ...@, Sep 6 2011

Dean - you wrote this in No 5 above about 3 years ago:
Comment 5 by, Sep 6, 2008
OK, marking as WontFix.  People can still comment on the bug if they feel it's 
important, and we can always revisit later on.
Status: WontFix

- I wrote this in comment 63 about 1 year ago:
Comment 63 by, Oct 4, 2010
I just downloaded Google Chrome to see what my website looks like on it, not knowing that the JS and Jquery would not work locally on my computer. I'm not bothered about all the reasons for this and I am not even going to try to fix it.  So I am now going to discard and forget all about Google Chrome.
Thank heaven for Firefox.

- WEll I just had a look at Chrome again, and I suggest you FIX IT. I just dumped Chrome again because of no JS on local host. And I am not going to try to fix it. But it woud be nice if you could explain to us all who have bothered to contact youe, why on earth it cannot be done. 
I really would like to test my Jquery stuff at home on my little website - but Google - he say No!!  See you next year... Cheers John Guise

Comment 76 by, Sep 7 2011

Hey guys, since it appears all comments here are missed by the development team, I created a new issue in hopes they at least add a warning for this issue:
Perhaps you can add your support to this issue, so when it gets picked up, the gravity of the issue is directly clear.

Comment 77 by, Sep 7 2011

Owner: ----

Comment 78 Deleted

Comment 79 by Deleted ...@, Dec 9 2011

I want Tiddly Wiki!

Comment 80 by, Mar 12 2012

THIS is what you have to do to enable local cookies for debugging on Mac OS X???

It's the only solution I've located after tons of searching.

From the 'geniuses' at Google, this is s super 'retarded' solution! Think. Harder. The app has about:flags to enable crazy features - put a damn 'enable local cookies' flag there if you cannot behave like ALL the other browsers do.

Comment 81 by Deleted ...@, Mar 27 2012

use instead of localhost and it works ;-)

Comment 82 by, Mar 27 2012

@81: OR http://localhost/ work if you're running a local web server. That's not the point.

The problem is that Chrome blocks cookies and doesn't even show a message in the log when you load something via file://

(For example, A TiddlyWiki file, which needs to be run from file:// to be editable)

Comment 83 by Deleted ...@, May 31 2012

Just discovered this issue. For me, the inability to check a setting to enable file cookies just ruined Chrome as a viable browser option. 90% of my web productivity is focused around TiddlyWikis, and losing options every time I close Chrome is simply unacceptable.

Currently, I'm going back to attempt to correct FireFox's stability issues rather than fight with Chrome over a simple option that people have been asking for for years.  When a browser breaks my goto productivity HTML file, I lose patience with the browser.

Comment 84 by, Jun 1 2012

Again I want to remind everyone that this issue is closed, so please also comment and star the following issue, perhaps they will have a look at it some time:

Comment 85 by, Aug 27 2012

Project Member
The following revision refers to this bug:

r153484 | | 2012-08-27T15:04:14.465102Z

Changed paths:

Rewrite the cookies pyauto test as browser tests.

I didn't port testCookiesFile since cookies aren't supposed to work on file urls by default (see ).

I removed all the duplicate code for getting cookies in browser tests and moved them to browser_test_utils.h.

BUG= 143637 
Review URL:

Comment 86 by, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 87 by, Jun 27 2013

 Issue 254688  has been merged into this issue.

Comment 88 by, Apr 24 2017

Project Member
The following revision refers to this bug:

commit a94b02ec68fb7fac617032b59c1705079ffd0dd7
Author: Dirk Pranke <>
Date: Mon Apr 24 18:31:18 2017

Disable a bunch of tests on Mac.

It looks like the xcode-ninja generator is at
least partially broken on 10.12/Xcode8.2, plus
a few other tests are failing. I've filed bugs
for each failure. I've also fixed a couple of
failures where it looks like the output
from various mac tools has changed slightly.,
BUG= 527 ,  529 ,  530 ,  531 ,  532 ,  533 ,  534 ,  535 

Change-Id: I59269afa860b4068173c00fced85154805a7f432
Reviewed-by: Nico Weber <>
Reviewed-by: Dirk Pranke <>
Commit-Queue: Dirk Pranke <>


Sign in to add a comment