Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
Hi Eric,
вторник, 9 сентября 2014 г., 7:08:43 UTC+4 пользователь 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);//]]/scriptapplet
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?
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
--
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
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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 -- 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.
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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 -- 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
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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);//]]/scriptapplet
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);//]]/scriptapplet
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.
--
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.
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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);//]]/scriptapplet
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
--
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.
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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 написал: 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 Am 25.08.2014 03:59 schrieb Eric Shulman elsd...@gmail.com javascript:: 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
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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. 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 написал: 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 Am 25.08.2014 03:59 schrieb Eric Shulman elsd...@gmail.com: 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
Re: [tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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 Am 25.08.2014 03:59 schrieb Eric Shulman elsdes...@gmail.com: 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 -- 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. -- 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.
[tw] Announcing TiddlyWiki Classic version 2.9.0 BETA1
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 -- 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.
