Skip to content


Subversion checkout URL

You can clone with
Download ZIP


File import macro broken in Firefox 5 #38

jdlrobson opened this Issue · 31 comments

This worked in Firefox 4, however in Firefox 5 try to import from a local TiddlyWiki file
When doing so the process fails and an error message:
Error getting list of tiddlers, click Cancel to try again

is displayed.

@martinbudden martinbudden was assigned

The problem seems to lie in the httpReq function

Note it is also impossible to import from a url.
The httpReq function seems to be failing.
Note the ajaxReq function does still seem to be working.

In terms of importing from a file:
Looking at this further it seems that the function httpReq fails when the file OUTSIDE the existing directory
A workaround in the meantime is to move the file into the same directory of the TiddlyWiki and do the import.


Good spot. We should be moving to directly using the jQuery ajax functions here anyway.

In terms of failing when outside the existing directory, that looks like a tightening up of Firefox security and may not be possible to avoid.


Yes. We could improve the error message for importing from files to say something along the lines of - "Please move file to same directory as TiddlyWiki as some browsers force this restriction"


Does this essentially cut off installing/upgrading plugins from (say) TiddlyTools?


Does this essentially cut off installing/upgrading plugins from (say) TiddlyTools?

You can install plugins by saving the file to disk, but automatic upgrades won't work. Incidentally, upgrading the wiki itself also is broken in Firefox 5, possibly for the same reason.


Does anyone have any additional info on what exactly Firefox 5.0 actually did? I vaguely remember some kind of mention of enhanced protections on file:// URLs, but nothing beyond that.

On the plus side, at least it's not too hard for me to install a copy of Firefox 4.0.1 for when I want TiddlyWiki imports, middle-click pasting, and resize snap-to in Panorama to work.


I've been looking through the Firefox 5.0 release notes, and more specifically, but have not yet found a specific reference to this change. I'll continue to read through the release notes, but if anyone else comes across the note associated with this change then please post it here.


I'm still trying to re-locate what I read, but I did discover this MozillaZine thread. If nothing else, it seems to provide a nice, simple testcase for a behaviour that worked in Fx4 and doesn't work in Fx5.


Doesn't look like it should overlap, but it could be an un-intended side-effect of that change.

I also ran across mention of some unification of cross-domain HTTP code in Fx5 (Something along the lines of fixing some duplication in the backend code for CORS and chrome/privileged XHR) on bugzilla while trying to see if anyone else had reported this problem (gave up when the search started causing trouble) and that could also be an easy place for a permissions check to get accidentally dropped or typo'd.

I'd link to it, but I viewed so many bugs that day that I'm having trouble getting something meaningful out of my browser history and can't afford to spend half an afternoon on it.


I'm also experiencing this issue in Google Chome, version 14.0.835.109.


Confirmed @scrosland
I get an error "ReferenceError: netscape is not defined" with the latest version when trying to import from a local file.

I'm looking at a host of import related problems today, so will report if I find anything new / can fix it...


The current state of affairs...
In Firefox 5, you can import from

  • a file in the same directory
  • a url which is COR enabled

In Chrome you can import from

  • a url which is CORs enabled
  • a file IF you open the file and pass --allow-file-access-from-files in the command line

The Chrome situation is quite unfortunate. The same with Firefox, but at least it still works.

I've found and trapped the netscape error posted by @scrosland and suggest we should have better guidance tips for dealing with the error situations...


This is a major stumbling block for users. I'm web developer and it took me hours to grasp the issue.

Has no one offered to supply a proxy to (and others) which sets Access-Control-Allow-Origin: *

It must be in the developers interest to supply such a (domain-)limited proxy function so folks can import:


Maybe the solution to importing remote plugins and keeping them synchronized is to approach the problem from a completely different angle. Here's a half-baked idea, no pun intended, which might spark one of you programming gurus to crafting a workable solution: add a field associated with all tiddlers, hash, which holds a hash value, e.g. MD5, for the tiddler. The overhead is low so performance shouldn't be impacted. The hash is generated/refreshed either upon explicit request of the author or implicit upon saving changes to the tiddler. I like the idea of explicit generation because it could provide a form digital signature for the tiddler. This would ensure that an author's plugin would only stay synchronized with instances of the plugin that had not been tweaked by other users. Anyway, everything about the import process could appear the same as is currently implemented. The difference would be that the mechanism for adding the tiddler to the TW would be to simulate creating a new tiddler and copying and pasting the title, key tiddler fields (e.g. author, created date), the body, tags, and most importantly the hash field from the remote TW into the new tiddler, i.e. use the clipboard. A successful import could be verified by running the hash generating function against the new tiddler to see if its' hash value matches the value from the remote TW. BTW, the hash value should be based on the tiddler title, all key fields, and the body of the tiddler. Tags should not be included. A nice feature to go along with effectively creating read-only tiddlers would be to be able to add comments to a tiddler that are not included in the hash.

Just spit-balling here. Hopefully something useful can be plucked or stumbled upon from this quagmire.


The core issue (at least for importing tiddlers currently) is the browser security and it's blocking of cross-domain AJAX. The only solution known to man (i.e. me :)) is to serve the tiddlers witht the right header (see above). Jeremy has kindly agreed to provide this feature so there will be a nice proxy for importing from some standard sources (e.g. or maybe How we import from non-standard sources is again a problem and depends on the provider of tiddlers/plugins offering the * on his Access-Control-Origin header.


There is some documentation of the current state of this problem here:

Note there are also issues with importing from local files in some browsers.

A proxy seems the best way to go for non file based tiddlywikis however creates a problem if that proxy ever goes down import will not work across any browser....


Closing this issue as it cannot be fixed by changes to TiddlyWiki itself. The problem has been manifested by increased browser security in all the major browsers. Server side changes (or possibly browser extensions) are required.


Just an info.
I didn't have a look to the plugin but it seems to be needed to change TW and serversides.


Bit confused @pmario - the UploadTiddlerPlugin that Paulo Soares has kindly fixed is not part of the TiddlyWiki distribution and relates to server sides (not TiddlyWiki)... so I'm struggling to see the relation to this problem which is about browser security... care to enlighten me? :)


I think the most reliable way to implement such a proxy would be to make it a single PHP file with support for enough HTTP request APIs that it can just be dropped into most web servers and set executable.

Then store the URL for it in a cookie-backed field (users who want to persist the setting can use SystemSettings) and make TiddlyWiki only use the proxy if a first attempt at a CORS-enabled XHR request fails. (And, if feasible, offer a default one so sending a TiddlyWiki to a newcomer is still reasonably problem-free if the customized URL hasn't been persisted)

I can spare an hour to whip up the PHP file if someone more familiar with TiddlyWiki's internals can make the changes to TiddlyWiki for me to test it against.


sry, my last post belongs to the TW upload to tiddlyspot problem. It may not belong to this issue.

It should have been addressed to @simonbaird. Hopefully, he'll see it now.
#38 (comment)


Does contain a possible solution for this? It looks like we could FileReader.readAsText('....') in HTML5 enabled browsers.

I'm not too familiar with the current (ex?) file loading/parsing code, but could this be a drop in replacement?


I'm looking into this.

However, it seems The FileReader API only seems to work off an http protocol on Chrome (ie. when run from a TiddlyWiki it would throw an error). I've not yet found a workaround. It seems to work OKAY in Firefox. I'll post something when I have something to show.


Hi @phillbaker (and other interested parties) I've re-written the file importer using the file api an it's available here - I would be interested in feedback and if there is a way we could push this into the core without effecting existing TiddlyWiki users who are not having any problems!


How to use it?


Just include the plugin and use file importer as normal. It should have a noticeably different UI!


Finally found a mention of what Firefox 5 actually did.


@jdlrobson: thanks for efforts. Here's feedback, as requested (though I didn't get far) : I made it to step 4 of the import (into tiddlyspot), and I was unsuccessful. No progress on the progress bar, for at least 5 minutes.
Step 4: Importing 0 tiddler(s)

I'm going to keep trying, by saving to a file, and importing in firefox...

UPDATE: I saved the plugin to a txt file. I get the following error: " A script from "" was denied UniversalFileRead privileges." when trying to import from a file. Then I get the same CORS error message as before when trying to import it.


@mroswell - it sounds like you are running from an old version of Firefox which is using the default TiddlyWiki import mechanism. You will only be able to make use of TiddlyFileImportr in a modern recent browser.

This plugin will only upgrade your browser if it is able to. I've updated the plugin to inform you better when it is running in the default method. Please download the latest version which will give you a "Please upgrade your browser " message above the file importer to make this clearer


I may have found what prompted Firefox devs to significantly lock down XHR access for file:// URLs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.