New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 40787 link

Starred by 164 users

Issue metadata

Status: WontFix
Email to this user bounced
Closed: May 2010
EstimatedDays: ----
NextAction: ----
OS: All
Pri: ----
Type: Bug

  • Only users with EditIssueCc and Commit permission may comment.

Sign in to add a comment

Local files doesn't load with Ajax

Reported by, Apr 8 2010

Issue description

Chrome Version: 5.0.342.7 (42476)
OS + version: Ubuntu 9.10 64-bit
Behavior in Linux Firefox: works correctly

Loading local files using ajax (e.g. jquery's methods) doesn't work. It 
makes it impossible to work with pages/apps on user's machine.

Simple test case attached.

Launching with --disable-web-security makes it work, but it's a bad 
workaround. I suppose it was designed to protect user's data to get read by 
Internet pages, but maybe local files from the local page's directory (and 
subdirectories) should be allowed by default?

could have access to:
/home/user/stuff/* in general?
523 bytes Download
23 bytes View Download

Comment 1 by, Apr 8 2010

Labels: -OS-Linux OS-All
Status: Assigned

Comment 2 by, Apr 8 2010

Use --allow-file-access-from-files as a "safer" workaround.

At work we have the same problem, which is a shame because we were hoping to support 
non-IE browsers with our app.  The "same directory" origin model Firefox uses also 
interferes but at least we could work around that at some point.

Only real workaround I could think of is to run a local web server and serve all 
content with that.

Comment 3 by, Apr 19 2010

Running a local server is mega-pain for cross-platform application - eg. we distribute 
map-based data on USB drives (up to 1TB even) and want anyone to be able to plug it in 
and access the data without having to install software. The FF policy works fine as 
does IE7+ with an appropriate system (eg jQuery) but we would like to support as many 
browsers as possible. (unless chrome has a zero-install, run from memstick model).
We have a CD-ROM of promotional material and the idea is for everything to be self-
contained without a web-server install.  All browsers we have tried except Chrome have 
worked loading the local pages without AJAX.  

However, it is not a solution to use a parameter such as --allow-file-access-from-files 
because we will not be with users as they "install" the CD-ROM.
Status: WontFix
Thanks for the notes.
Depending on the level of feedback on the stable release, we might adopt a model 
closer to Firefox. Although that would of course be a shame. Chromium now has the 
strongest file security of the major browsers and it would be nice to keep it that 

I would recommend using something simple like a Python script to serve the files via 
localhost. This will work on all browsers and use the standard Same Origin Policy.

Comment 6 by, May 26 2010

This is disastrous news. A "dont use Chrome notice" to our clients. Your python script 
idea might work for all browsers but then python must be installed. It isnt by default 
in windows. The html-based systems on local files allows no-install, multi-OS delivery. 
No ajax severely restricts what we can do inside this. Creating great security by 
removing common, useful functionality doesn't impress at all. Lets hope safari doesnt 
follow this cop-out too.

Comment 7 Deleted

Comment 8 Deleted

This is a serious problem and may actually be a bug, at least in some situations. On
Windows Chrome 5's js console is now claiming illegal js calls between frameset and
frame content components that are all in the same folder with the same credentials,
so it is difficult to see how they could be genuinely violating same origin rules. 

The Google programmers may not be familiar with how HTML is being used for
documentation nowadays. CHM files are now frequently replaced with browser-based
Webhelp, also on local installations, where you need to load topics into objects,
iframes or frames to get a decent navigation interface in help systems with a large
number of topics. The current behavior makes this kind of documentation completely
inaccessible in Chrome. 

Comment 10 by, May 27 2010

@helpmanpro Sadly that behavior is by design.  Access between other files even in the 
same folder is prohibited via XMLHTTPRequest and cross-frame scripting.

I'm not sure why the same domain policy has to go any further than the local 
computer.  Data only needs to be restricted there... who cares if a webpage can read 
your credit card numbers by blinding guessing filenames in your profile directory, it 
can't actually do anything with them if access to internet resources is properly 

I can only imagine there are concerns about 1) arbitrary plugins that may have 
security holes to bypass Chrome's restrictions and 2) inclusion of http:// scripts 
which may allow XMLHTTPRequest callbacks to those domains from that script (not sure, 
does this work?).

The current restrictions wouldn't even stop #1 or #2 (again, not sure if #2 works at 
all in the first place, but #1 is still a valid concern).

Any valid vector for a malicious HTML file getting to a user and the user being 
tricked to open it is now far more effective simply by substituting an EXE file, and 
under Windows you can even give it an icon and fake filename so it looks like an HTML 
file when viewed in Explorer, since file extensions are hidden by default.  The EXE 
file has no restrictions other than a "from the Internet" prompt.  Far less 
restrictive than Chrome's restrictions if you ask me.  At least Firefox's same folder 
policy is workable... nice "middle ground" so to speak.

Although to also be fair, outside of work I have never seen any examples of HTML 
documents that the security restriction here negatively impacts.  In THEORY it could 
impact many; in practice I haven't seen any examples, at least not recently that I 
can recall.  Except one I am helping to develop at work, of course.
@megazzt Well, actually ( ;-) ) a very large number of HTML-based documentation
systems depend on this. The scenario is that you have hundreds or even thousands of
pages of documentation files organized with a collapsible TOC (table of contents)
tree pane on the left and the topic display pane on the right, emulating Windows' CHM
viewer. Even though frames are evil, if you want backward compatibility with old
browsers they are still the least expensive way to manage this. 

For the dynamic version you then need cross-frame scripting to synchronize the TOC
with the display, and Chrome then throws a hissy fit. I haven't tested it yet, but my
guess is that the same thing will happen in iFrames if you use them instead of a
classic frameset. But that would be something that would have to be developed for the
future -- it won't help all the countless thousands of users who must now stop using
Chrome because their documentation no longer works. :-/
@helpmanpro: the frame navigation issue with (e.g.) Javadoc is separate from XHR 
access, and is being tracked as
id=39767. As you can see, that bug has been fixed in WebKit and will be shipped in a 
Chrome 5 patch before long.

@megazzt, @Scaddens: if you really need XHR-like functionality between local files, 
there are workarounds. I understand that the Python suggestion may not have gone over 
well; here are some possibly more palatable solutions:

1) Use <script src>. This standard facet of the web model will let cross-origin files 
declare themselves as public data by e.g. being a variable declaration, or JSONP).

2) For a more advanced version of data sharing than <script src>, you could look at 
the relatively new postMessage API. All major browsers now have it:

Essentially, where the cross-origin model is too restrictive, there are standard ways 
for collaborative content to allow itself to be read cross-origin.

Adopting 1) or 2) above will also mean you are in good shape for if and when other 
browsers raise their file security to Chrome's level.

Comment 13 by, May 31 2010

@12 Thanks but neither of those allow us to load XML files from the local disk, 
something our app relies heavily on for configuration.
As a workaround, the XML files can be changed e.g.
From: <xml>blah</xml>
To: receivexml('<xml>blah</xml>');

By defining a receivexml() function in the party who wants to read the file and 
loading it with <script src>, you get access to the XML text which you can then parse 
etc. as normal. Will work on all browsers.

Comment 15 by, May 31 2010

That's a pretty ugly hack, plus we would have to change around pretty much our entire 
system... and we'd lose syntax highlighting, and external DTD loading (which we rely on 
to validate the XML) would be more complicated at best.

Of course we're in a feature freeze right now so it's not like we can mess around with 
any major changes right now anyway.

Comment 16 by, May 31 2010

scarybeasts - thanks for those comments. It still seems ironic that we are using
methods for cross-origin access when in fact this is SAME-ORIGIN file access that we
want. I need to look at <script src> as it isnt obviously to me how you could use
this without in fact loading EVERY JSONP at startup rather than on request. Its
designed for fetching JSONP from a cross-domain server selectively loading from local
file. I just want ajax to fetch a json file from current origin on demand.

postmessage looks interesting but still anything but likewise not that clear how you
would use it to load a local JSON file in response to user click. I need to look
through a lot more examples. 

On second thoughts, I do see how <script src> is supposed to work for selectively
loading a file, (tag injection), but for local files there is problem of how to wrap
it for a callback. Without this, there is problem of synchronicity. You just shouldnt
have to do this for same-origin.

For postmessage, I am right in thinking that method is supposed to be create a hidden
iframe in response to click on link, which loads a page containing the JSON and then
uses postmessage to send data to main page?

Comment 18 by, Jun 1 2010

We've actually been injecting <script src>s for loading scripts, but I think Chrome 
blocks these as well.  I think we were using an onload event on the script tag for a 

Comment 19 by Deleted ...@, Jun 1 2010

megazzt - according w3 documentation script doesnt have a onload event??? Could you 
check please how you are doing the callback? (Academic if chrome blocks it).

Comment 20 by, Jun 1 2010

Actually Chrome doesn't block them... I was mistaken.

I am not at work at the moment so I can't check.  script onload might not be a standard 
but whatever we are using is supported by IE7, Chrome, and Firefox.  Maybe 
document.onload?  I forget.  That part of the app was written long before I was hired.
Yes, I have found that you call back from the loaded script to page directly. Now to
me this script tag injection for cross-site javascript seems like an almighty
security hole compared to ajax access to same-origin local file which for life of me
I cant see how you could exploit without user intentionally downloading html file and
starting it.
Looking yet further into this, I realise it will break jQuery JSONP implementation
too. jQuery converts JSONP request to ajax for same-origin and only use script tag
injection for cross-domain.
@#21: Unfortunately, downloading and running HTML files is a common paradigm. Think 
HTML repro attachments in a bug database system ;-)

I think a good approach to address this issue would be to introduce a "about:config" type window that allows developers / advanced users to selectively choose this (+ other) option.

This is particularly useful (I've found) for doing local automated testing using qUnit.
I struggled quite a lot before finding out about this flag. 
Would it be possible to do a log in the console to warn the user (who is likely to be a developer) that a local file was accessed and that you might want to turn this flag on to allow it ?
In addition to #c25, browser can ask the user whether to allow the access to local file or not when such XHR occurs.  It can also give options for allowing or rejecting further accesses from that page as well.

WontFix'ing this issue seems a very bad decision to me.
@jaeho.shin: see, comment #56 for why asking the user is a bad idea.

Comment 28 by, Jul 26 2010

If I am correct, in the future you will be able to just provide a crx-file (Installable Webapp) for the chrome-users and it will work correctly. It will be double, but it will work. At the moment however current chrome-installations don't have this active by default, and it might take some time before they do.
This bug should really be merged with
Wow just wanted to say I pulled my hair out for about 2 hours before finding this thread. Be great to allow developers to switch this on/off.

Comment 31 Deleted


Like many small users I use a web browser only on my own computer (not on a server). I know Microsoft tries to make this difficult and forces us to use active X and all their stuff,  but I want to use Chrome.

Unfortunately, Chrome allows no way to do something like open a text document in the same folder as my javascript program (html file). So Chrome is useless and I am forced to use vbs files and all the microsoft nonsense.

Too bad that Chrome has disabled itself for local files completely. In other browsers I can read the innerHTML of an iframe. A strange little thing to do but it is what lots of small users do who do not have access to a server.

Also, I'd like to be able to show my friends my programs too without having them install anything, it would be great if Chrome didn't think that two html files in the same exact folder are on different domains!

Too bad Chrome is different from every other browser in this unfortunate way.

PS I attach a copy of my 'word unscrambler' which works in all browsers except Chrome. It consists of an html file and a txt file that go in the same folder.

1.1 MB View Download
4.1 KB View Download

Comment 34 Deleted

Hi Hugh, I will try it exactly as you say. Maybe I didn't wait for it to
load. I will write back later to tell you if it worked.

Comment 36 Deleted

It does work after all. It is just necessary to start Chrome with the flag --disable-web-security. 

You know, a lot of people don't understand that the reason computer viruses came about is that Microsoft made it so difficult to access the internet. To make a 'hello world' html file you can't save it as 'myfile.html'  in Notepad. It actually gets saved as 'myfile.html.txt' with the txt hidden. You have to go to a lot of trouble to unhide the txt and when you change it to html there is a hard-coded warning saying not to do it,  etc. 

So people trusted Microsoft to deliver applications to them, and in the process trusted anyone else who could set the invisible extensions. So it was about Microsoft trying to get hold of our accounts, really, and in the process opening a vulnerability.

Now Google is doing the same but the opposite. They are making it almost impossible to access your own local file structure unless you are online and using a server -- such as their server. I can access a .txt file from Google Documents, say, but not if I am offline, programmatically from my browser, unless I go through a whole complicated thing.

So just as Microsoft  purposely made it difficult to write a page for a server, Google is making it difficult to write a page for anything except a server. Firefox allows a person to bring a whole binary file into their browser. Not Google. The door is closed and locked to your own file system. 

It is an unfair and sharp business practise, and against the motto 'do no harm.'

--disable-web-security is very dangerous. --allow-file-access-from-files will loosen access control in the way you probably want but with less security headache.

The --allow-file-access-from-files flag  no longer works since the last
update of Google Chrome. It is just very strange that I can use the file
upload feature on my copy of Google Chrome to upload a file to any server in
the world and access it that way, but there is no way to use <input
type=file> to access files when you are not online, without using the
--disable-web-security flag.

Google is trying to create a 'security firewall' that excludes the local
file system, but it is motivated more by their wish to have everyone use
cloud computing, and less from real security concerns.
Ah yes, it works as -allow-file-access-from-files  (with one hyphen at the

Comment 41 by, Oct 13 2010

Arrgh! running into another brick wall with this one. I am using webmapping application and vector information for maps is in KML. Guess what happens if you try to load a KML into the webmap? This!

"XMLHttpRequest cannot load file:///H:/eclipse/PBE/WebContent/data/TWT/TWT.kml. Cross origin requests are only supported for HTTP."

Of course, its not cross-origin but a local file. This webmapping is for running on machines a very long way from internet access so local file is only option. So what is the bright workaround for this? Please dont say put "requestKML(...) into the kml file. 

Comment 42 by, Oct 28 2010

I know this is now also related to 47416, but that is closed for comments. At the very least, could Chrome relax security to FF type local directory access when there is NO internet connection active? In this situation, its obvious that local file access is intentional.
 Issue 60867  has been merged into this issue.
 Issue 63591  has been merged into this issue.

Comment 45 by Deleted ...@, Nov 19 2010

Has this been fixed? I see a the status WontFix and this really worries me. 

I am developing a CRX extension, and I really need this to make my code more modular. Otherwise, making a single page/local app become very cumbersome and inefficient. 
The --allow-file-access-from-files switch works for Windows 7, but isn't working on XP. It's bad enough having this issue, but it's really annoying that even the workaround isn't working... I'm on 7.0.517.44 - is anyone else having the same problem?
Use just one hyphen at the beginning -allow-file-access-from-files

My mistake - I was running Google Calendar as an application shortcut which was opening before Chrome proper, so I didn't consider that I'd have to set the flag in my Calendar shortcut as well! Thanks.

Comment 49 Deleted

Please do not take this in a condescending manner, I respect the work that the development team completes to ensure data security and prevent cross site vulnerabilities.

I maintain a data gathering "error reporting" script project that generates many data files based on system commands and log extraction. This script also generates a report file that needs to load local text files from the archive, which resides on the disk. 

As others have mentioned, the bug does not deserve a work-around. It deserves a coded solution or viable universal solution. Each work-around proposed seems to take what I call a "Microsoft" approach to the issue: "Code it for my browser." (there is a period at the end indicating argument is futile)

In a situation like this I abandon support for the browser and support the legacy versions rather than adopting emerging technology solutions such as HTML 5 and other variations that will only work on new generation browsers. 

With many corporations out in the world, the newest browsers and versions of standard tools are not always addressable to the end user. For instance, IE 6 and IE 7 are still used in many companies due to dependence of enterprise level web applications. 

I happen to install, customize, and support one of these enterprise applications, which supports a limited selection of browsers. For each of these browsers we have to code specific items to allow the application to have cross browser support. 

This bug is not only very intrusive to the developer of Chrome supported applications, but also not seen in the other major players in the same market, including Microsoft IE.

As a long time supporter of the Google product line, I find it disappointing that this is not only closed, but not considered a medium or high priority defect. 

This has been stated many times before, but it is worth another mention: "This is not a multiple domain/source issue. It is dealing with the same source localhost"

For instance, it could easily be translated to an administrative share if file sharing were enabled:


The goal of the browser developer should be security, flexibility, and support of standard usage. I see a failure in two out of the three of these items. 

Comment 51 Deleted

In response to comment 46:

I also cannot get this flag to work in XP.

I think at the very least it would be nice to have a warning that says AJAX app blocked.  I thought my script was broken in chrome until I got an old version out and noticed that an old script wasn't running.
 Issue 66553  has been merged into this issue.
I've been working on writing some javascript unit tests but ran into a very annoying error when I was loading the dojo tool kit. Since I'm using custom dojo builds, the dojo files are separated and once dojo tries to load in its modules/files Chrome chokes claiming "Cross origin requests are only supported for HTTP." I read the above comments but I am not convinced that Chrome's approach is more secure than Firefox's. While *I* may be able to work around this issue, I would like to see a simple solution to allow loading of files within the same or child directories of where the script is located.
This also doesn't work for packaged apps in the Web Store. If anything should have a security exception (since all the files are local), packaged apps should. I can't even acces manifest.json to grab the version number!

Comment 56 by, Jan 24 2011

I'm a little unnerved that this issue has been open so long. It makes dev work very difficult and having this set to "WontFix" means I'll have to switch back to using Firefox as primary browser.

Comment 57 by, Jan 24 2011

Actually all you need to do is add a switch to your Chrome shortcut (and additionally a switch or two to the registry if you want .htm files and http:// handlers to use it).

Though it would be nice for this functionality to be under about:flags for easier access and usage.
Sorry I'm not good at English...very very!
And I can't read all entry in this thread.
But I have an idea. Please hear my idea...
This idea maybe "secure", "test easy", "no server soft install", "CD-ROM and USB demo OK", and "better than FF approach".

1. When local script needs AJAX to local file F.
2. Chrome check file "" in F's directory.
3. Chrome check entry for F in "".
4. Chrome arrow access if step 3 success.

- It is "secure", unless malware can't access to file "" in target directory.
- It is "test easy" and "no server soft install", "CD-ROM and USB demo OK", because all things tester needed is write file "".
- It is "better than FF approach", because we can access any file, regardless file directory.

more nurvous idea.

0. When local page at URI L.
3. Chrome checks entry for F+L in "".

Thank you for reading my poor English (and idea???).

Comment 59 by Deleted ...@, Mar 15 2011

Dumb. You score no points by taking away functionality we're used to. If you can't do it right, then don't do it at all.

Comment 60 by, Mar 15 2011

--allow-file-access-from-files does indeed work in XP, I use it at work.
Does not work on Chromium - 10.0.648.133 (77742) on Ubuntu 10.10

Neither --allow-file-access-from-files (or a single hyphen in the beginning)
nor --disable-web-security work.

If there is still debate on how this issue will be resolved, can the command line options disabling this be made to work again, for all us devs who need this to test html/js locally ?

Comment 62 by Deleted ...@, Apr 10 2011

Another reason to have those 2 flags work is in the case of my company's products: we use HTML5 for a kiosk-like application, just like the ones in the airport.

These products are critical and must run at all times. I use local files to collect and track diagnostics on memory and CPU and so forth.

Since those 2 flags do not work in my client's build of Chroimium, we are migrating back to Firefox... which we abandoned over a year agoi in favor of Chromium.

Just my 2 cents.
If a supported command-line flag has stopped working, that sounds like a new issue that should be filed as a new bug with a detailed test case, including exactly which version used to work and which version no longer works.
Our local web-based manpage documentation application uses AJAX w/JSON to navigate. We have had to add a  'Not supported on Google Chrome/Chromium' on all the pages because of this issue.
I've found a way around the security restriction using a combination of JavaScript and Flash. A Flash application compiled with the Local Only security sandbox setting will allow for loading of files from the hard drive when accessed locally.

JavaScript calls to the Flash application to load files (.html, .xml, .json) and Flash returns the data to the specified JavaScript callback.

I've created a project on Google Code if anyone is interested:

Comment 66 by, Jun 26 2011

Just want to add my support behind getting this issue fixed with a common solution. When developing I like to test on a wide range of browsers with json test data stored locally. Due to this restriction I can't. This problem is one of the only reasons(an important one) the compnay I work for can't support chrome

Comment 67 by Deleted ...@, Jul 7 2011

There is no debate. This is BROKEN behavior. BUG BUG BUG BUG BUG.

Developers create local logs in HTML. Modern logs save as JSON and viewer pages use getJSON to render the information. If you can't trust the file hardcoded in the html page and sitting right next to it on the file system, what the hell can you trust?


I spent an hour studying Flask, a micro Python web framework, to overcome this limitation.

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

I write canvas game, and I would really want to store levels in local xml files, so the game would run the same from the server, and downloaded to disk on any system.

The problem is - in Chrome/Chromium it doesn't work.

This is serious problem for single player game. I use java script mainly because it works on any system without any installation required.

Every step required from user in order to run program is a big obstacle.

Please, provide a way for this to work. Maybe if script tries to do this, show user a dialog with option "Switch to off-line mode in order for this page to work" - if user accepts, allow accessing local files by ajax, but disallow sending information outside.

Comment 70 by Deleted ...@, Jul 31 2011

To get round this use a script tag not XMLHttpRequest. Here's an crude example with JSON.

First create a javascript string version of your JSON string using an alert, then copy it to clipboard.

var obj = {
    num: 1,
    test: "test 'this' and \\ this and \"this\" ",
    arr: [1,2,3],
    ob: {a:1,b:2}

var js = "var jsonText = '" + JSON.stringify(obj).replace(/\\/g,"\\\\").replace(/'/g,"\\'") + "';"

Paste the result into a local file called say jsonTest.js, then add a parse line, and alert. You should get this:-

var jsonText = '{"num":1,"test":"test \'this\' and \\\\ this and \\"this\\" ","arr":[1,2,3],"ob":{"a":1,"b":2}}';
var objViaJson = JSON.parse(jsonText)

Then get the file from your local html page using:-

<script type="text/javascript" src="jsonTest.js"></script>

So you don't need to use a .json file and XMLHttpRequest, just a plain old script tag, with any origin policy, and little prospect of that changing since it's used for online ads. Mind you they could scupper script any origin for local files I guess.

You could do similar for xml data as pointed out above.

Comment 71 by, Aug 14 2011

This is absolutely a bug, that disappoint me so much. If it is a security concern then Google should provide the users an option to bypass it. Needless to say almost all the other major browsers support this feature without being considered as less-safe than Chrome.

Google is shutting the door to access the local files. I guess someday they will eventually disable the use of <img> to access local images. lol

Comment 72 by, Aug 14 2011

The Chrome team most certainly has provided bypasses.  The first is the command line option --allow-file-access-from-files, the second is Apps, which allows for you to package up a directory of files and XHR works fine within that package.  I've used both methods successfully at work with our app (which works well with the app format; may not work as well for other stuff like simple documentation).

There is no need for hyperbole here or slippery-slope arguments, it won't help us reach a solution here.

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

this is stupid - just fix it. 

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

This is really nasty and unusable. Using browser on local (file://) html/ajax/json file is totally impossible due to this stupid "security" rules...

file:// URLs always produce a null Origin, so the first page is null Origin, but if this page try to access another file in same subdirectory it lead to  XMLHttpRequest error " null is not allowed by Access-Control-Allow-Origin "

For me Access-Control-Allow-Origin must be only enable when page come from other resource than a null one. This have no sense in (file://) local mode.

This lead Chrome to be unusable as local browser from my point of view.

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

And here I thought Chrome was going to be the lead browser on apps. No, it's not, it's just as bad ("YES DO HARM") as any other mega-corporation in trying and push their policy.

Adding a tag to your shortcut is WORSE than old html/script hacks in the PAGE, it's retrograde, it's lame.

I want so hard to believe chrome, to believe Google, but day by day, news by news, it becomes so very evident that the BUGGY(?) and FLAWDED(?) ways of Microsoft are way better: it works from the premise you should and can do whatever you want, as in a REAL TURING MACHINE, instead of blocking what the mega-corp thinks is best

Google is going APPLE on it's users.

Comment 76 by Deleted ...@, Sep 13 2011

it's just unbelievable that there is no solution for that!
can't use chrome in local mode? so whats the point to use it for development?
even some "disabled" setting could be nice.
Labels: Restrict-AddIssueComment-EditIssueCc
@looknear: thanks for your comment.
There _is_ a command line flag to turn on local file access for development. It seems like this information has gotten lost in the noise, so sorry about that. Anyway, here it is:
Project Member

Comment 78 by, Oct 13 2012

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.
Project Member

Comment 79 by, Mar 11 2013

Labels: -Area-Undefined

Sign in to add a comment