TWC saving with chrome, still bugged??

189 views
Skip to first unread message

Sparrisen987

unread,
Nov 25, 2013, 12:30:44 PM11/25/13
to tiddl...@googlegroups.com
I haven't seen any additional topics with this lately?

Anyway, it stopped working after a java update.

1: Today, I tried updating the my tiddlywiki, and it couldn't create a backup, so it couldn't save the file, so it wouldn't update.
-Then I tried IE, which got an "error code" message

2: Then i downloaded the new version (I had vesion 2.6) and imported the tiddlers instead
2b: Then I tried to save, but now it says "Downloading/saving main tiddlywiki file" but nothing happens, and there's no new backup file in the folder, and the original file is unchanged.

__________________
I guess this is not fixed yet?

Can I perhaps make it work in TW5 somehow, if classic isn't working?

thanks

Eric Shulman

unread,
Nov 25, 2013, 1:45:28 PM11/25/13
to tiddl...@googlegroups.com
On Monday, November 25, 2013 9:30:44 AM UTC-8, Sparrisen987 wrote:
2b: Then I tried to save, but now it says "Downloading/saving main tiddlywiki file" but nothing happens, and there's no new backup file in the folder, and the original file is unchanged.

That message indicates that the normal TiddlySaver.jar method of saving is failing, and the fallback "download save" handler is being triggered.  However, this *should* result in either a dialog box prompting for a location to save the file, or the file being directly saved to your designated "download" folder.  It appears that neither of these actions is occuring in the current version of Chrome.  This functionality *DID* work in previous browser revisions (though I'm not sure when it stopped working).

I am actively investigating, and hope to have this fixed shortly.

enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios

EVERY DONATION IS IMPORTANT!
HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

Professional TiddlyWiki Consulting Services...
Analysis, Design, and Custom Solutions:

Sparrisen987

unread,
Nov 26, 2013, 10:12:51 AM11/26/13
to tiddl...@googlegroups.com
Alright... As soon as you solve this, i would really like to know. I've been stocking up on work to do with my tiddler ever since the java got bugged.

thanks

Gary Barker

unread,
Dec 3, 2013, 6:55:59 AM12/3/13
to tiddl...@googlegroups.com
Did this problem ever get solved?
Saving in Chrome stopped working for me a month or more ago. Today I tried starting from a fresh empty.zip version but Chrome simply resorts to downloading a new version to my Downloads folder every time it saves which isn't any use. TiddlySaver.jar is definitely in the folder with the wiki.

Regards,
Gary

Eric Shulman

unread,
Dec 3, 2013, 12:03:17 PM12/3/13
to tiddl...@googlegroups.com
On Tuesday, December 3, 2013 3:55:59 AM UTC-8, Gary Barker wrote:
Did this problem ever get solved?
Saving in Chrome stopped working for me a month or more ago. Today I tried starting from a fresh empty.zip version but Chrome simply resorts to downloading a new version to my Downloads folder every time it saves which isn't any use. TiddlySaver.jar is definitely in the folder with the wiki.

The fallback "download saver" is trying to save your document **with your changes**.  When TiddlySaver.jar (or the other local file I/O handlers) fail, TiddlyWiki triggers the browser's built-in "download a file" mechanism to attempt to save the file by simulating a download event.  The downloaded file is actually constructed on-the-fly from the current tiddler content loaded in your browser (including any new/changed tiddlers), rather than merely making a copy of the previously saved file.  Most browsers allow you to change the download settings so that it will *ask* for a target filename and folder, rather than defaulting to your Downloads folder.  With this setting active, you can navigate to the current document folder, and select the active document to overwrite it with the updated content.  Of course, the browser will ask for confirmation before overwriting.

I am still looking into some reported problems with the download/save fallback mechanism.  It *was* working for all major browsers, and still seems to work for many users, but may have run afoul of recent browser updates for some people on some platform/OS configurations.  I am working on putting together the next TiddlyWiki Classic update (v2.8.2), in which I hope to include some possible fixes or workarounds to provide a more consistent fallback handling experience.  Unfortunately, due a major family crisis (my Mother had a stroke two days before Thanksgiving!), I've been quite distracted recently.  Although I cannot reliably state when that update will be posted, my intention is to release it by the end of this month.

-e

Gary Barker

unread,
Dec 3, 2013, 12:33:23 PM12/3/13
to tiddl...@googlegroups.com
Thank you for the quick update and I'm sorry to here about your mother. 
I have the simple workaround of using Internet Explorer which isn't a massive hardship for me. Families come first.


--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/gZM8gxKGSV8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/groups/opt_out.



--
G+: https://plus.google.com/u/0/104223712160178727877/posts

Vincent Yeh

unread,
Dec 3, 2013, 9:49:48 PM12/3/13
to tiddl...@googlegroups.com
Yes, families always come first. Take good care, Eric.

PVHL

unread,
Dec 4, 2013, 6:48:19 PM12/4/13
to tiddl...@googlegroups.com
Java 7 update 45 broke local, signed TiddlySaver use, and update 25 (IIRC) broke the official, signed jar. The _45 bug is both denied by Oracle support and stated to be fixed in update 51 coming in January. I am hoping to have a signed working jar for use with 51 by the time it is released, but Oracle keeps changing the rules.

I uploaded an unsigned jar to my GitHub fork (the TiddlySaver1JarAlpha branch), but it requires changing the Java policy file as explained in another post. The only way I was able to save with TWC using Chrome, my unsigned jar, and update 45 was to modify my system policy file, but I use the portableApps version of Chrome on Windows 7 Enterprise, so YMMV. BTW, the only change made to the Java code was to set a flag that disabled the local directory checking code that was obsoleted. (I have had reports through another project that it is working with Chrome on a Linux install.)

It didn't seem worthwhile to release a signed jar that only worked pre-update-45; I offered it if wanted, but had no takers. I can add the signed jar (renamed) to the GitHub fork if desired, but it won't work with updates 45+, and I haven't tested it with earlier Java versions yet, but it was officially signed (no time currently to wreck my Java setup and then fix it again :0). Perhaps better to wait for the next update, see if the signed jar bug is fixed, and release a working signed jar at that time if it is.

Cheers, Paul.

Fred Hayes

unread,
Feb 25, 2014, 9:33:55 PM2/25/14
to tiddl...@googlegroups.com
The solution that seems to be working for me has to do with these Chromes settings, which are configured using command line options. The following CL options seem to have fixed my issues with saving. I've tried to implement it in the registry [HKLM\SOFTWARE\Classes\ChromeHTML\shell\open\command]
 so that Chrome always starts with these options, worked great last night, but to my suprise today this key seems to have reverted back to its original value. I'll have to look into that more. You can create a shortcut to call Chrome with these switches. The CL switches are "  --enable-file-cookies and --allow-file-access-from-files  ". 
Fred
Reply all
Reply to author
Forward
0 new messages