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 -- 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.
