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 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
