Announcing TiddlyWiki Classic version 2.9.0 BETA1

[Eric Shulman]

Greetings all!

I'm very pleased to announce that TiddlyWiki Classic version 2.9.0 BETA1 is now available for download and testing, here:

    http://classic.tiddlywiki.com/beta

This long-delayed update to TiddlyWiki Classic includes fixes or improvements for open issues and pull requests related to some common problems encountered by TiddlyWiki users, authors and developers.  Here's a quick list of items that have been resolved:

112: Allow international characters and leading/trailing whitespace in slice names

132: URLs containing square brackets not recognized

147: Transclusion problem on startup

154: Parametric transclusion doesn't work properly with refreshing

156: Fix javaDebugInformation function

157: Improve the String.prototype.escapeRegExp utility

159: Cookies are not working in Opera

160: Remove the syncing item from the default ToolbarCommands

161: Make new tiddlers open below below the one containing newTiddler macro

162: Substitute missing arguments of parametric transclusions with an empty line

166: Use default editmode text for themes with non-standard template names

Please download this BETA release at your earliest opportunity and test using content from your existing TiddlyWiki Classic documents to verify that these changes correct any problems you were experiencing while not introducing any new problems for documents that was previously working as desired.

The plan is to make a full release of TW290 as soon as it can be confirmed that the update does not break AMBIT (http://ambit.tiddlyspace.com), a TiddlySpace-based application that is being used daily by a large, active user base of over 1000 mental health care providers throughout the UK.  Hopefully, the AMBIT testing and verification process can be completed quickly, so TW290 can be promoted to full release within the next few weeks (or even sooner).

Moving forward beyond TW2.9.0....

While the existing "ecosystem" of TiddlyWiki Classic offers a rich environment of mature plugins and document "applications" that will continue to provide a great deal of value and utility for some time to come, there is currently no intention to add significant new code or features to the TiddlyWiki Classic core codebase, as the future of TiddlyWiki clearly lies with the power of TiddlyWiki5.

Nevertheless, there are still some currently open issues and pull requests for TiddlyWiki Classic, and any new problems with TiddlyWiki Classic should continue to be reported.   The plan is to make a few, more frequent, incremental updates (e.g., TW291, 292, etc.) while TiddlyWiki5 continues its progress towards a stable mainstream release.  Once that occurs, a "final" update to TiddlyWiki Classic... version 3.0.0... will be built and released.  

Of course, I will continue to provide online help and support for existing TiddlyWiki Classic documents and plugins for the foreseeable future, as long as there a need for that help.  However, once TW5 is out of beta, my primary focus will shift to creating and publishing a TW5 version of TiddlyTools and developing new plugins for TiddlyWiki5, as well as writing TiddlyWiki5 documentation (perhaps an actual book?!?) and providing user support for the "migration path" from TiddlyWiki Classic to TiddlyWiki5 (i.e., guidelines and scripts for converting existing documents).  

enjoy,

-e

Eric Shulman

TiddlyTools / ELS Design Studios

YOUR DONATIONS ARE VERY IMPORTANT!

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

   http://TiddlyTools.github.com/fundraising.html#MakeADonation

Professional TiddlyWiki Consulting Services...

Analysis, Design, and Custom Solutions:

   http://www.TiddlyTools.com/#Contact

[ocalTW]

Thank you Eric.

Just a quickie for all of those willing to download this new version: there is a slight error in the download link.
It should start with "classic" instead of "www" in the "download now..." link on http://classic.tiddlywiki.com/beta
The correct link is : http://classic.tiddlywiki.com/beta/empty.zip

PS. So far, so good with the tests I've done with many of my TWCs running under 2.8.1.

[Eric Shulman]

On Monday, August 25, 2014 12:41:17 AM UTC-7, ocalTW wrote:

Just a quickie for all of those willing to download this new version: there is a slight error in the download link.
It should start with "classic" instead of "www" in the "download now..." link on http://classic.tiddlywiki.com/beta
The correct link is : http://classic.tiddlywiki.com/beta/empty.zip

I've corrected the download link.  Much thanks, ocal, for that good catch.

There was also an error in the slider for showing issue #166 that has now been fixed.

-e

[whatever]

Hi!
I have a strange occurrence, possibly a bug. It might be related to issue 159. Namely, in TiddlyMarks (1) I use cookie values to determine the view. When opening a local version of TiddlyMarks with core version 281 (on TiddlySpot it's 261) in the latest Waterfox, Internet Explorer and Safari, then opening a local version of TiddlyWiki 290beta1 and then refreshing TiddlyMarks, the cookie value for the theme gets surrounded by double-quotes. The same happens for other cookie values. I opened an empty TW281 (after I opened TW290beta1) and the empty values in the Tweak Backstage menu now contain two double-quotes. The double-quotes are absent in TW290beta1. Closing the browser (Waterfox and IE, but NOT Safari) and opening a TW281 resolved the issue. Also, opening an online version of TW290beta1 didn't seem to cause the issue. TW261 doesn't seem to be affected. Opera works normally. I'm on Windows 7.

Also, additional issue in Safari. I keep getting the following message: Java is unavailable.
When I click Cancel, the popup keeps reloading every now and then. I used the latest TiddlySaver.jar.

(1) http://tiddlymarks.tiddlyspot.com

w

[whatever]

Hi!

I tried on a different computer as well, this time with Java 7.63 (the other had earlier versions). The Java prompt issue in Safari persisted, but not the double-quote issue. The double-quote issue also disappeared in Waterfox, but not in IE (64-bit, btw). I also tested in Chrome, which doesn't seem to be affected. Also, not just empty values in the Tweak menu contain quotes, other values have them as well, except for some reason txtUserName.

w

[Eric Shulman]

On Monday, August 25, 2014 10:33:09 PM UTC-7, whatever wrote:

I tried on a different computer as well, this time with Java 7.63 (the other had earlier versions). The Java prompt issue in Safari persisted, but not the double-quote issue. The double-quote issue also disappeared in Waterfox, but not in IE (64-bit, btw). I also tested in Chrome, which doesn't seem to be affected. Also, not just empty values in the Tweak menu contain quotes, other values have them as well, except for some reason txtUserName.

You are almost certainly correct in your assumption that this is a side effect of the fix for issue #159.  Here's some background:

In TW281 and earlier, the TWCore "packs" all the various option name/value pairs into a single text string to be stored as a browser cookie.  This string uses double-quotes to surround the individual option values for all the currently defined TiddlyWiki options.   This string could be something like:

   chkSomeThing:"true" chkSomeThingElse:"false" txtSomeText:"gleep" txtSomeEmptyText:""

However, as reported in issue #159, the use of double-quotes within a cookie value is NOT valid, according to the W3C specs.  As a result, some browsers will fail to save the TiddlyWiki options and reject the cookie, preventing the option values from persisting between TW sessions.

The most direct fix for this, is to avoid storing the literal double-quotes by encoding/decoding them using their hexadecimal code, %22.  Thus, in TW290b1, after packing the option values into a string (as shown above), the literal quotes are converted to %22 before saving to the browser as a cookie.  Then, when that cookie value is read back in, the embedded %22 sequences are converted back to literal quotes before unpacking the options into their individual TWCore config.options[...] run time storage locations.

Although this works as intended, and does "solve" the problem by not storing quotes in cookies... it presents a small backward-compatibility issue:  as you noted... if you modify the TiddlyWiki option cookie using TW290, and then read that cookie using an earlier release (e.g., TW281), then that earlier release does not know to decode the %22 sequences, and they are left in place as part of the individual unpacked option values.  Thus, an option which is blank in TW290, will have a value of %22%22 in TW281, which will appear as a pair of double quotes (e.g, "") when displayed.

If you upgrade ALL your working TW documents to TW290, then the "cookie quote" handling will be the same across all documents, and you shouldn't see any more double quotes appearing in the option values.  Of course, it may not be practical to upgrade *all* your documents right away, and you can always open a TW document that was sent to you by others, which could still trigger the errant double-quote handling if it is based on an older version of the TWCore.

One possible way to address this:

I could make the new encoding/decoding handling *optional*, with the default being to leave the double-quotes alone, as before.  That way, if you are working in a mixed environment with both TW290 and older versions, the cookie value created by TW290 will still be compatible with the older versions of TW.  The new handling option would only need to be enabled by users when their browser has been actually been rejecting cookies because of embedded quotes.  A hard-coded zzConfig tiddler containing something like:

config.options["chkEncodeCookieQuotes"]=true;

would do the trick.

Does that seem like a workable solution for your situation?

your thoughts?

-e

[whatever]

Hi!

Well, for me personally, upgrading isn't a problem, but it might be for some people, so your proposed solution would definitely come in handy.

w

[Albert Riedinger]

Hi Eric,

thank you for this update! I'm glad to see that TWC development doesn't stop at all. I will test and report as soon as possible.

Regards,
Albert

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, 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/d/optout.

[Yakov]

Hello Eric,

now, this is great and inspiring!

Confirming fixes:

112 & 154: fixed, works, will close the issue (154) shortly

157: fixed, doesn't need testing, will close the issue shortly

160: fixed, doesn't need testing, will close the issue shortly

162: fixed, works, will close the issue shortly
161: fixed, works, will close the issue shortly
159: fixed, works; is it really necessary to surrond all the values with %22...%22? Even one-word, like true/false or numbers, like txtMaxEditRows:30? (it would ease migrating)
As far as I can see (from [1-3]), that would work as expected in both versions of cookie-handling.
147: I'll report later, more investigation needed

I have a major problem though: I failed to save the new TW using TiddlySaver in these 4 combinations:
Windows 7 x64 + Opera 12.17 +
either my PC with old Java (as far as I can see 7 update 17) or another PC with the latest (7 update i-don't-remember-which) +
either old TiddlySaver I still use or the new one in the package.
On trying to save, the console sais:

javaLoadFile: TypeError: 'applet.loadFile' is not a function
javaSaveFile: TypeError: 'applet.saveFile' is not a function

javaDebugInformation() gives:

"Java Version: TypeError: Cannot convert 'method' to object

Last Exception: TypeError: Cannot convert 'method' to object

Last Exception Stack Trace: TypeError: Cannot convert 'method' to object

System Properties: TypeError: Cannot convert 'method' to object"

and that's in each case, including the fresh installation on the other PC.

Best regards,
Yakov.

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Options.js#L61
[2] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Strings.js#L241
[3] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Strings.js#L117

четверг, 28 августа 2014 г., 11:53:27 UTC+4 пользователь Albert Riedinger написал:

[Yakov]

ps

пятница, 29 августа 2014 г., 22:55:40 UTC+4 пользователь Yakov написал:

Confirming fixes:

112 & 154: fixed, works, will close the issue (154) shortly

sorry, I meant more investigation is needed for this one

157: fixed, doesn't need testing, will close the issue shortly

160: fixed, doesn't need testing, will close the issue shortly

162: fixed, works, will close the issue shortly
161: fixed, works, will close the issue shortly

closed these ones

159: fixed, works; is it really necessary to surrond all the values with %22...%22? Even one-word, like true/false or numbers, like txtMaxEditRows:30? (it would ease migrating)
As far as I can see (from [1-3]), that would work as expected in both versions of cookie-handling.

 

[Leo Staley]

Oh this is pertty cool. I think this post should be stickied for a while.

[TheDiveO]

On Monday, August 25, 2014 3:59:29 AM UTC+2, Eric Shulman wrote:

However, once TW5 is out of beta, my primary focus will shift to creating and publishing a TW5 version of TiddlyTools and developing new plugins for TiddlyWiki5, as well as writing TiddlyWiki5 documentation (perhaps an actual book?!?) and providing user support for the "migration path" from TiddlyWiki Classic to TiddlyWiki5 (i.e., guidelines and scripts for converting existing documents).  

Eric, please write an actual book (as in actual ebook) on TW5 ... I will immediately buy and gladly pay for it! An O'Reilly "TW5 in a Nutshell" would be great. With insight for both beginners and hackers/customizers.

[Eric Shulman]

On Friday, August 29, 2014 11:55:40 AM UTC-7, Yakov wrote:

159: fixed, works; is it really necessary to surrond all the values with %22...%22? Even one-word, like true/false or numbers, like txtMaxEditRows:30? (it would ease migrating)
As far as I can see (from [1-3]), that would work as expected in both versions of cookie-handling.

Although many option values are single words, numbers, or true/false, option values *can* contain whitespace, so at least some of the time, there is a need for the surrounding quotes.  However, a valid browser cookie should not contain any quotes, and cookies containing quotes are rejected by some (but not all) browsers. This is the basis for issue #159, which reported that Opera did not save the TiddlyWiki option values between sessions.  Although I have not confirmed, I think that this error was also responsible for preventing options from being saved in other browsers as well.

TWClassic uses String.encodeHashMap() [1] to construct a space-separated string of name/value pairs, where each option name is followed by a colon (:), and the option value is *always* enclosed in double-quotes, like this:

name1:"value1" name2:"value2" name3:"value3"

The fix for #159 did not change the way the individual option values are encoded/decoded from the cookie text.  Rather, it simply converts the *existing* use of quotes to %22 to avoid being rejected by the browser.  Of course, since most option values are single-words, numbers, or true/false, we could reduce -- but not completely eliminate -- the use of quotes in the encoded cookie text, by changing String.encodeHashMap() to check for whitespace in the option values, and only adding the surrounding quotes when actually needed.  The resulting cookie text would still need to have any quotes encoded as %22, so those option values could still be affected by the "version skew" issue that #whatever reported above.

So.. I now have two possible improvements for the 159 fix:

1) maintain backward-compatibility by adding a chkEncodeCookieQuotes option (default to false) to completely bypass the %22 encoding/decoding.  This will allow continued use of a mixed version environment (i.e., TW2.8.1 or earlier running along side TW2.9.0) for browsers that DO accept cookie values containing quotes.  Of course, because the cookie text would then contain quotes, browsers that DONT accept quotes will reject any changes to default option settings; thus, to enable the %22 encoding for those browsers, the TW author cannot simply "set an option checkbox" (as that setting would not be saved).  Instead, they would need to explicitly add a systemConfig tiddler containing:

config.options.chkEncodeCookieQuotes=true;

2) reduce (but not eliminate) the use of quotes in cookie text by checking for whitespace in String.encodeHashMap().  This limits the impact of the %22 encoding, so that MOST option values would be backward compatible unless they contain whitespace.

My only concern about solution (2) is that String.encodeHashMap() is not only used to encode the option cookie text, but is also used in the TWCore for some handling of custom fields.  A quick review of the code suggests that it would be "safe", but I prefer to keep changes as isolated as possible to minimize their any unexpected impact on existing TiddlyWiki uses.

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Strings.js#L249

I have a major problem though: I failed to save the new TW using TiddlySaver in these 4 combinations:
Windows 7 x64 + Opera 12.17 +
either my PC with old Java (as far as I can see 7 update 17) or another PC with the latest (7 update i-don't-remember-which) +
either old TiddlySaver I still use or the new one in the package.
On trying to save, the console sais:
javaLoadFile: TypeError: 'applet.loadFile' is not a function
javaSaveFile: TypeError: 'applet.saveFile' is not a function
javaDebugInformation() gives:
"Java Version: TypeError: Cannot convert 'method' to object
Last Exception: TypeError: Cannot convert 'method' to object
Last Exception Stack Trace: TypeError: Cannot convert 'method' to object
System Properties: TypeError: Cannot convert 'method' to object"

and that's in each case, including the fresh installation on the other PC.

Hmmm... I'm not sure what's happening here, but I don't see any problems using the new TiddlySaver.jar with Chrome, so perhaps it's an Opera bug?  Here's some info that might suggest an avenue of investigation to persue:

• The TiddlySaver.jar included with TW290 was re-built about 6 months ago by PVHL (to update the Certificate), and came from here:
  

   https://github.com/PVHL/tiddlywiki/tree/TiddlySaver1Beta1/java

• The only TWCore code change related to TiddlySaver was a fix to javaDebugInformation() to correct an erroneous function name.  Note that javaDebugInformation is NOT called by the TWCore, and is only provided for use with debugging tools, so it should have NO effect on loading or using the TiddlySaver.jar, regardless of the version.
  

Your thoughts?

-e

[Eric Shulman]

I would LOVE to write a book about TiddlyWiki.  The only catch... is that it takes a lot of time and undivided attention.  Unfortunately, because I am a self-employed software consultant, I have to spend a great deal of day-to-day effort on finding and earning income from various client projects, and TiddlyWiki inevitably get pushed to a lower priority until the monthly bills are paid.  Of course, if there was a enough income from TiddlyWiki to cover my monthly living expenses without other client work, I would gladly spend all of my time exclusively on writing the TiddlyWiki book.

Jeremy and I have been discussing how to make this happen, and we've been talking about creating a Kickstarter campaign in order to raise enough funds for me to work full-time on the book.

To do this, we need to decide on an outline of topics the book should address.  Once we have a proposed "Table Of Contents", I can then estimate how long it is likely to take to write that material. That will, in turn, help determine the initial funding goal and any "stretch" goals needed to complete the work.

We will also need to structure the Kickstarter campaign to provide various "rewards" for different levels of funding from contributors, so your ideas for campaign rewards that you think people would like are also important.

Your thoughts?

-e

[TheDiveO]

Eric,

just my two cents here: personally, I'm heavily interested in better understanding the architecture of TW5 and how to customize and extend it. Some topics I could imagine:

• more basic: parameter evaluation ... so when do the parameters to a macro call, et cetera, really get evaluated? Most of the time I'm scratching my head as I still haven't properly understood how TW5 works. Somehow I often manage to get a working solution but have the same feeling I always had with TeX: does it get digested in TeX's mouth or stomach ... same feeling here with TW5 parameter processing.
  
• how does the TW5 core establish and maintain (tiddler) dependencies, so that when one tiddler changes other dependent tiddlers and elements work? How can I extend such automatic dependencies?
• so this brings me to: how to develop widgets and how to they establish and use the aforementioned dependencies?
• the architecture of TW5; boot process; additional processing, et cetera...

Of course, there is so much more...

[Danielo Rodríguez]

The book itself would be a very nice reward! I will pay for it for sure

[Eric Shulman]

On Sunday, August 31, 2014 7:37:26 AM UTC-7, TheDiveO wrote:

Eric,

just my two cents here: personally, I'm heavily interested in better understanding the architecture of TW5 and how to customize and extend it. Some topics I could imagine...

I think there are several types of presentation that we should target:

* User-level introduction to TiddlyWiki concepts and usage

* Authoring guidelines (customization using tags, templates, macros, stylesheets, etc.)

* Developer guidelines (creating plugins, themes, etc.)

* Syntax reference (wikitext, macros, widgets, messages, etc.)

* Case studies / Design Patterns / Examples

The topics you've suggested would seem to fall into the authoring and/or developer categories, with a bit of cross-linking to the syntax reference and at least one example/case study to illustrate usage.

-e

[Yakov]

Hello Eric,

воскресенье, 31 августа 2014 г., 12:05:09 UTC+4 пользователь Eric Shulman написал:

On Friday, August 29, 2014 11:55:40 AM UTC-7, Yakov wrote:

159: fixed, works; is it really necessary to surrond all the values with %22...%22? Even one-word, like true/false or numbers, like txtMaxEditRows:30? (it would ease migrating)
As far as I can see (from [1-3]), that would work as expected in both versions of cookie-handling.

Although many option values are single words, numbers, or true/false, option values *can* contain whitespace, so at least some of the time, there is a need for the surrounding quotes.  However, a valid browser cookie should not contain any quotes, and cookies containing quotes are rejected by some (but not all) browsers. This is the basis for issue #159, which reported that Opera did not save the TiddlyWiki option values between sessions.  Although I have not confirmed, I think that this error was also responsible for preventing options from being saved in other browsers as well.

TWClassic uses String.encodeHashMap() [1] to construct a space-separated string of name/value pairs, where each option name is followed by a colon (:), and the option value is *always* enclosed in double-quotes, like this:

name1:"value1" name2:"value2" name3:"value3"

The fix for #159 did not change the way the individual option values are encoded/decoded from the cookie text.  Rather, it simply converts the *existing* use of quotes to %22 to avoid being rejected by the browser.  Of course, since most option values are single-words, numbers, or true/false, we could reduce -- but not completely eliminate -- the use of quotes in the encoded cookie text, by changing String.encodeHashMap() to check for whitespace in the option values, and only adding the surrounding quotes when actually needed.  The resulting cookie text would still need to have any quotes encoded as %22, so those option values could still be affected by the "version skew" issue that #whatever reported above.

So.. I now have two possible improvements for the 159 fix:

1) maintain backward-compatibility by adding a chkEncodeCookieQuotes option (default to false) to completely bypass the %22 encoding/decoding.  This will allow continued use of a mixed version environment (i.e., TW2.8.1 or earlier running along side TW2.9.0) for browsers that DO accept cookie values containing quotes.  Of course, because the cookie text would then contain quotes, browsers that DONT accept quotes will reject any changes to default option settings; thus, to enable the %22 encoding for those browsers, the TW author cannot simply "set an option checkbox" (as that setting would not be saved).  Instead, they would need to explicitly add a systemConfig tiddler containing:

config.options.chkEncodeCookieQuotes=true;

 

2) reduce (but not eliminate) the use of quotes in cookie text by checking for whitespace in String.encodeHashMap().  This limits the impact of the %22 encoding, so that MOST option values would be backward compatible unless they contain whitespace.

My only concern about solution (2) is that String.encodeHashMap() is not only used to encode the option cookie text, but is also used in the TWCore for some handling of custom fields.  A quick review of the code suggests that it would be "safe", but I prefer to keep changes as isolated as possible to minimize their any unexpected impact on existing TiddlyWiki uses.

I think it would be ok to add a new argument to String.encodeHashMap:
String.encodeHashMap = function(hashmap,dontForceQuots)
and in those places where it was used previously, no changes will be applied unless the new argument is used. If dontForceQuots is true, quots around one-word values are not put.

As for the Java issue, it is probable that the old Opera is the source of the problem: after some tweaking, I succeeded in saving in Yandex browser (Chromium-based); I have to test saving to/including from an outer relative folder, though.

Best regards,
Yakov.
 

[Mat]

First of all - thank you for the new TW update!

Second, regarding a book; I will definitely buy it. However (ah, here I go) would it not be better with a digital book so that it can be updated easily? Or maybe it is a digital version you're talking about?

With the risk of a thread-jacking; How about a book written in TW? From an educational/explanatory point TW has an absolute powertool namely sliders! Sliders allow different levels of depth in an explanation or description and in a form that allows the reader to stay in one place as opposed to hyperlinks.

<:-)

[Yakov]

Trying to make TW 2.9.0 save in Opera 12.17, I started to trace what's going on and here what I've found:

0. TW that I'm currently using is 2.7.1, so I'm not sure yet if the problem arised in 2.9.0 or in 2.8.0/2.8.1
1. In 2.7.1 and 2.9.0 javaSaveFile has the same code. I decided to test TW 2.9.0 with the old TiddlySaver which works for me with TW 2.7.1.
2. When I press "save changes", javaSaveFile is actually called, the exception is applet.saveFile is not a function. applet = document.applets['TiddlySaver']
3. In TW 2.7.1 (and old TiddlySaver), if I write in console
document.applets['TiddlySaver']
I get
<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>
In TW 2.9.0 (and old TiddlySaver), I get (!)
HTMLCollection [<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>, <applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>]
At the same time, if I do this in Chrome, I get
<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>
in both cases.

Also, the same thing (HTMLCollection) appears instead of the applet in Opera with the new TiddlySaver. So, this is the reason why saving doesn't work..

Best regards,
Yakov.

понедельник, 8 сентября 2014 г., 16:13:18 UTC+4 пользователь Yakov написал:

[Eric Shulman]

On Monday, September 8, 2014 10:36:16 AM UTC-7, Yakov wrote:

Trying to make TW 2.9.0 save in Opera 12.17, I started to trace what's going on and here what I've found:

0. TW that I'm currently using is 2.7.1, so I'm not sure yet if the problem arised in 2.9.0 or in 2.8.0/2.8.1

I suspect it might actually be a problem with the fallback "download save" handler from 2.8.x.

If TiddlySaver.jar failed to load in 2.8.x, then the fallback handler has to reconstruct the original source file from the contents of the loaded document, rather than reading it from the filesystem.

Unfortunately, the document image from the loaded document (document.documentElement.outerHTML) is *not* identical to the original file content (though it is very close).  One of the differences is that, during startup, the TWCore uses document.write() to conditionally *add* the "<applet>...</applet>" code to the HTML, but only when the "useJavaSaver" flag is set (which it *is* for Opera).  To address this, the recreateOriginal() function, invoked by the fallback handler, 'fixes up' the document image by *removing* the applet element that was added during startup.

It's possible that when using Opera with 2.8.x, a failed attempt was made to load TiddlySaver.jar (perhaps due to one of the Java runtime updates that broke the signed/unsigned use of privileged file I/O functions... now corrected by PVHL's update).  This failure to load TiddlySaver.jar would then trigger the fallback handling, which in turn would invoke recreateOriginal().  However, if the "remove the added applet" code didn't work for some reason (perhaps it didn't *exactly* match the embedded applet syntax generated by Opera?), then the file would be written using the fallback handler with the <applet>...</applet> intact, and the next time the file was loaded, *another* <applet>...</applet> block would be added, resulting in the applet being loaded twice... and I suppose that could cause it to fail, even with the new, 'fixed' TiddlySaver.jar.

1. In 2.7.1 and 2.9.0 javaSaveFile has the same code. I decided to test TW 2.9.0 with the old TiddlySaver which works for me with TW 2.7.1.
2. When I press "save changes", javaSaveFile is actually called, the exception is applet.saveFile is not a function. applet = document.applets['TiddlySaver']

This suggests that the JavaSaver.jar failed to load properly.  Thus, while the loaded applet object exists, the saveFile method might still be undefined, resulting in the error you see.

 

3. In TW 2.7.1 (and old TiddlySaver), if I write in console
document.applets['TiddlySaver']
I get
<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>

That looks correct.

 

In TW 2.9.0 (and old TiddlySaver), I get (!)
HTMLCollection [<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>, <applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>]

Uh oh.. that's not right.  The value of document.applets['TiddlySaver'] returns an HTMLCollection with two applets, rather than just one.  It looks like there are TWO "TiddlySaver" applets loaded at the same time, which would be a likely side-effect of the potential problem with recreateOriginal() that I described above.

At the same time, if I do this in Chrome, I get
<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>
in both cases.

That's correct.

 

Also, the same thing (HTMLCollection) appears instead of the applet in Opera with the new TiddlySaver. So, this is the reason why saving doesn't work..

Not surprising... if the problem is the errant doubling of the <applet>..</applet> block, then the problem will appear regardless of the version of TiddlySaver.jar you attempt.

Some things to try:

1) One way to look for confirmation of the problem, search the entire TW document source using a full-text editor, to see if a hard-coded <applet>...</applet> block exists (other than the conditional one present in the document.write()).  If such a block is found... try removing it from the document and then repeat your experiments to see if that fixes the problem.

2) in Opera, examine the value of document.documentElement.outerHTML, and see what <applet>...</applet> block(s) it contains.  Then, use the browser's debugger to invoke manually recreateOriginal() and see if the returned value contains any "extra" <applet>...</applet> blocks.

Let me know what you find out.  I'd like to post an updated Beta2 as soon as possible, but only after we solve this problem, or at least properly understand what is happening.

Much thanks,

-e

[Yakov]

So,

 

In TW 2.9.0 (and old TiddlySaver), I get (!)
HTMLCollection [<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>, <applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>]

Uh oh.. that's not right.  The value of document.applets['TiddlySaver'] returns an HTMLCollection with two applets, rather than just one.  It looks like there are TWO "TiddlySaver" applets loaded at the same time, which would be a likely side-effect of the potential problem with recreateOriginal() that I described above.

By the way, with the old TiddlySaver, this bad-semantics fixer plugin enables saving:

javaSaveFile = function(filePath,content)
{
	var applet = document.applets['TiddlySaver'];
	if(applet instanceof HTMLCollection) // YL tweak
		applet = applet.item(0);
	try {
		if (applet && filePath) {
			return applet.saveFile(javaUrlToFilename(filePath), "UTF-8", content);
		}
	} catch(ex) {
		logTiddlySaverException("javaSaveFile", ex);
	}
	// is this next block working anywhere ? -- grmble
	try {
		var s = new java.io.PrintStream(new java.io.FileOutputStream(javaUrlToFilename(filePath)));
		s.print(content);
		s.close();
	} catch(ex2) {
		return null;
	}
	return true;
}

 

At the same time, if I do this in Chrome, I get
<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>
in both cases.

That's correct.

 

Also, the same thing (HTMLCollection) appears instead of the applet in Opera with the new TiddlySaver. So, this is the reason why saving doesn't work..

Not surprising... if the problem is the errant doubling of the <applet>..</applet> block, then the problem will appear regardless of the version of TiddlySaver.jar you attempt.

Some things to try:

1) One way to look for confirmation of the problem, search the entire TW document source using a full-text editor, to see if a hard-coded <applet>...</applet> block exists (other than the conditional one present in the document.write()).  If such a block is found... try removing it from the document and then repeat your experiments to see if that fixes the problem.

No saved blocks in the source.
 

2) in Opera, examine the value of document.documentElement.outerHTML, and see what <applet>...</applet> block(s) it contains.

There's 2 applet blocks. After the definition of the TW21Saver.prototype.externalizeTiddler method, there's this part:

//]]>
</script>
<script type="text/javascript">
//<![CDATA[
if(useJavaSaver)
    document.write("<applet style='position:absolute;left:-1px' name='TiddlySaver' code='TiddlySaver.class' archive='TiddlySaver.jar' width='1' height='1'></applet>");
//]]>
</script><applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"></applet>

<script id="jsdeprecatedArea" type="text/javascript">
//<![CDATA[
//--
//-- Deprecated Crypto functions and associated conversion routines.
//-- Use the jQuery.encoding functions directly instead.
//--

then some deprecated code and some other goes (which is not repeated), and in the end of the text:

// Remove existing style sheet
// options.id is an optional name identifying the style sheet
// options.doc is an optional document reference
$.twStylesheet.remove = function(options) {
    options = options || {};
    var id = options.id || defaultId;
    var doc = options.doc || document;
    var el = doc.getElementById(id);
    if(el) {
        el.parentNode.removeChild(el);
    }
};

})(jQuery);

//]]>
</script>
<script type="text/javascript">
//<![CDATA[
if(useJavaSaver)
    document.write("<applet style='position:absolute;left:-1px' name='TiddlySaver' code='TiddlySaver.class' archive='TiddlySaver.jar' width='1' height='1'></applet>");
//]]>
</script><applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"></applet>
<!--POST-SCRIPT-START-->

<!--POST-SCRIPT-END-->


</body></html>
 

 Then, use the browser's debugger to invoke manually recreateOriginal() and see if the returned value contains any "extra" <applet>...</applet> blocks.

No applet blocks in the returned value.

Best regards,
Yakov.

[Eric Shulman]

On Monday, September 8, 2014 1:18:40 PM UTC-7, Yakov wrote:

So,

In TW 2.9.0 (and old TiddlySaver), I get (!)
HTMLCollection [<applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>, <applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"/>]

Uh oh.. that's not right.  The value of document.applets['TiddlySaver'] returns an HTMLCollection with two applets, rather than just one.  It looks like there are TWO "TiddlySaver" applets loaded at the same time, which would be a likely side-effect of the potential problem with recreateOriginal() that I described above.

By the way, with the old TiddlySaver, this bad-semantics fixer plugin enables saving:

javaSaveFile = function(filePath,content)
{
	var applet = document.applets['TiddlySaver'];
	if(applet instanceof HTMLCollection) // YL tweak
		applet = applet.item(0);
	try {

That makes sense... though it really doesn't address the root cause of the problem, which is that TWO copies of the applet are being loaded (or attempted), which Opera apparently doesn't like.

 

2) in Opera, examine the value of document.documentElement.outerHTML, and see what <applet>...</applet> block(s) it contains.

There's 2 applet blocks. After the definition of the TW21Saver.prototype.externalizeTiddler method, there's this part:

...

then some deprecated code and some other goes (which is not repeated), and in the end of the text:

...

$.twStylesheet.remove = function(options) {
...

})(jQuery);
//]]>
</script>
<script type="text/javascript">
//<![CDATA[
if(useJavaSaver)
    document.write("<applet style='position:absolute;left:-1px' name='TiddlySaver' code='TiddlySaver.class' archive='TiddlySaver.jar' width='1' height='1'></applet>");
//]]>
</script><applet style="position:absolute;left:-1px" name="TiddlySaver" code="TiddlySaver.class" archive="TiddlySaver.jar" width="1" height="1"></applet>

Well.. that's not right!  Way back in TW2.4.0 and earlier, the "if(useJavaSaver)" code occurred after the "externalizeTiddlers" function definition... However, in TW2.4.3(?) the deprecated code portion was added.  Looking around the archives (http://classic.tiddlywiki.com/archives), I don't see a revision that had BOTH instances of 'if(useJavaSaver)', and the current revision only has the one at the end (as intended).

HOWEVER... I *vaguely* remember something a long time ago about a .recipe that might have included the if(useJavaSaver) portion twice.  Exactly what version of TW is the document with the doubled code?

I suspect that if you simply remove the first occurrence of the if(userJavaSaver) code from that document, the problem would go away.

Of course, even if this does fix it, it doesn't explain how two instances of that code got in the file in the first place.  The problem MIGHT be 'historical', in that the problem was only with a specific revision, and it won't re-occur as long as you are no longer using that version (or hand edit the file as suggested above).  Still, it would be useful to figure out exactly how and when the problem was first introduced, so it can be documented for others who may encounter it.

 Then, use the browser's debugger to invoke manually recreateOriginal() and see if the returned value contains any "extra" <applet>...</applet> blocks.

No applet blocks in the returned value.

Yes.  It appears that recreateOriginal() is correctly removing both added applet blocks as intended.  My initial *guess* that this was a possible culprit is apparently incorrect, and I am now working on the theory that the double loading of the applet code was a build artifact from an earlier release.

-e

[Yakov]

Hi Eric,

вторник, 9 сентября 2014 г., 7:08:43 UTC+4 пользователь Eric Shulman написал:

The document I've tested is the new beta of 2.9.0 (major: 2, minor: 9, revision: 0, beta: 1), but..

First, I have to complain that the version archive is not updated and the latest version available [1] is 2.6.5. Fortunately, I've found a copy of 2.8.1 that I saved some time ago.

Second, all my TWs are now 2.7.1, so between that and 2.9.0, there's only 2.8.0 and 2.8.1. I took the saved 2.8.1 (no beta) and tested it as well. With the old TiddlySaver, it does save, and there's only one applet. So, this duplicating problem seems to be introduced precisely in 2.9.0.

[1] http://classic.tiddlywiki.com/archive/
 

I suspect that if you simply remove the first occurrence of the if(userJavaSaver) code from that document, the problem would go away.

Aha. The source of 2.9.0 beta 1 contains two of these blocks:

<script type="text/javascript">
//<![CDATA[
if(useJavaSaver)
    document.write("<applet style='position:absolute;left:-1px' name='TiddlySaver' code='TiddlySaver.class' archive='TiddlySaver.jar' width='1' height='1'></applet>");
//]]>
</script>

And yes, removing the first one from the source code fixes the issue (for the old saver, I have to test the new saver separately, as on my PC the old Java version is installed). Moreover, my "redefine the applet variable" fix doesn't work with SaveAsPlugin, while this does.
 

Of course, even if this does fix it, it doesn't explain how two instances of that code got in the file in the first place.  The problem MIGHT be 'historical', in that the problem was only with a specific revision, and it won't re-occur as long as you are no longer using that version (or hand edit the file as suggested above).  Still, it would be useful to figure out exactly how and when the problem was first introduced, so it can be documented for others who may encounter it.

Well, I have almost no idea how TWc is cooked, so I would hardly help here unless given some introduction.

Best regards,
Yakov

[Eric Shulman]

On Friday, September 12, 2014 1:54:27 AM UTC-7, Yakov wrote:

Aha. The source of 2.9.0 beta 1 contains two of these blocks:
<script type="text/javascript">
//<![CDATA[
if(useJavaSaver)
    document.write("<applet style='position:absolute;left:-1px' name='TiddlySaver' code='TiddlySaver.class' archive='TiddlySaver.jar' width='1' height='1'></applet>");
//]]>
</script>
And yes, removing the first one from the source code fixes the issue (for the old saver, I have to test the new saver separately, as on my PC the old Java version is installed). Moreover, my "redefine the applet variable" fix doesn't work with SaveAsPlugin, while this does.
 

Of course, even if this does fix it, it doesn't explain how two instances of that code got in the file in the first place.  The problem MIGHT be 'historical', in that the problem was only with a specific revision, and it won't re-occur as long as you are no longer using that version (or hand edit the file as suggested above).  Still, it would be useful to figure out exactly how and when the problem was first introduced, so it can be documented for others who may encounter it.

Well, I have almost no idea how TWc is cooked, so I would hardly help here unless given some introduction.

Oh dear!  This does seem to be a build-related issue!  I'm digging into it.  I think it's a recipe/template problem, but I'm not sure where.

-e

[ocalTW]

Hello

TWC 2.9.0 beta3 has been published without notice on November 3rd according to
    http://classic.tiddlywiki.com/beta
Any hint for the 2.9.0 official release?
TIA

Regards

On Monday, August 25, 2014 3:59:29 AM UTC+2, Eric Shulman wrote:

[Eric Shulman]

On Sunday, November 16, 2014 2:30:12 PM UTC-8, ocalTW wrote:

TWC 2.9.0 beta3 has been published without notice on November 3rd according to
    http://classic.tiddlywiki.com/beta
Any hint for the 2.9.0 official release?

As noted, TW290b3 has been posted online since November 3rd (just before I left on holiday).  However, before being officially released from beta, it must be tested in on TiddlySpace with AMBIT (a TiddlySpace-based TW "application" that is in active production use by over 1000 people!).  Once this testing is completed successfully, TW290 will be released.  The timetable for that is not yet determined, but it hopefully be sometime in the next few weeks, and almost certainly before the end of December.

Note: you can test the TW290 beta against your own TiddlySpace-hosted pages by adding "?twrelease=beta" to the end of your usual TiddlySpace URL.

-e