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 написал: > > 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. > > >> [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.
