Suggestion for alternate twFile driver order (to reduce browser security warnings)

[John Murphy]

I noticed the twFile TiddlySaver driver works on all major browsers but it's not the preferred driver on IE and FF. It's great IE and FF have their own native drivers, but they both result in disruptive security dialogs.

I successfully modified twFile to always try the TiddlySaver driver first and fall back on the native drivers. Is there any reason not to do this? In addition, the Java LiveConnect driver works on FF without security dialogs. This driver is slower, but it might be faster than dismissing a security warning! (JavaLiveConnect has a definite pause in Opera, but it's pretty snappy in FF.)

How about making the twFile driver order configurable? Or change it to the following order: ["tiddlySaver", "activeX", "javaLiveConnect", "mozilla"]

I have attached a patch detailing the changes I made to twFile.js Any comments are appreciated. I am also thinking of adding a function: $.twFile.ready(handler) that will be called as soon as twFile can process files (it checks by intermittently trying to load the file at "document.location.")

John

Notes: twFile driver support (stars* indicate number of security warnings)

ActiveX: IE***

Mozilla: FF*

TiddlySaver: IE**, FF, Opera, Chrome/Safari

JavaLiveConnect: FF [slight pause], Opera (v <= 10.0)[very slow]

[I could swear IE supported TiddlySaver and JavaLiveConnect without security dialogs, but now I can't reproduce it... Just an empty <script> tag results in a warning; JavaLiveConnect doesn't even work.]

Browser versions

IE: 8.0

FF: 3.5.11

Opera: 10.61 + 10.00

Chrome: 6.0

Safari: 5.0.1

Environment

Windows 7

Lenovo X301

-- 

www.leftium.com

[Jeremy Ruston]

> I noticed the twFile TiddlySaver driver works on all major browsers but it's
> not the preferred driver on IE and FF. It's great IE and FF have their own
> native drivers, but they both result in disruptive security dialogs.
> I successfully modified twFile to always try the TiddlySaver driver first
> and fall back on the native drivers. Is there any reason not to do this?

The reason was to avoid the dependency on the external file, which has
to be managed to a certain extent, kept up to date and so on.

I've done some experimentation with making it possible to unpack the
tiddlysaver.jar from the main TiddlyWiki file:

http://autotiddlysaver.tiddlyspot.com/

> In
> addition, the Java LiveConnect driver works on FF without security dialogs.
> This driver is slower, but it might be faster than dismissing a security
> warning! (JavaLiveConnect has a definite pause in Opera, but it's pretty
> snappy in FF.)

I hadn't realised that LiveConnect worked in Firefox. It looks like
they've been improving it recently:

https://developer.mozilla.org/en/LiveConnect

Interesting.

> How about making the twFile driver order configurable? Or change it to the
> following order: ["tiddlySaver", "activeX", "javaLiveConnect", "mozilla"]

I like the idea of making it configurable, and would worry that
changing the default would be too disruptive in the field with the
installed base.

> I have attached a patch detailing the changes I made to twFile.js Any
> comments are appreciated.

> I am also thinking of adding
> a function: $.twFile.ready(handler) that will be called as soon as twFile
> can process files (it checks by intermittently trying to load the file at
> "document.location.")

Is there a lighter weight way of checking? Some TW files are quite large.
> John

> Notes: twFile driver support (stars* indicate number of security warnings)
> ActiveX: IE***
> Mozilla: FF*
> TiddlySaver: IE**, FF, Opera, Chrome/Safari
> JavaLiveConnect: FF [slight pause], Opera (v <= 10.0)[very slow]

> [I could swear IE supported TiddlySaver and JavaLiveConnect without security
> dialogs, but now I can't reproduce it... Just an empty <script> tag results
> in a warning; JavaLiveConnect doesn't even work.]

I don't think I ever got TiddlySaver working on IE, but I could easily
be wrong, it was quite a long time ago.

Many thanks,

Cheers

Jeremy

> Browser versions
> IE: 8.0
> FF: 3.5.11
> Opera: 10.61 + 10.00
> Chrome: 6.0
> Safari: 5.0.1
> Environment
> Windows 7
> Lenovo X301
> --
> www.leftium.com
>
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWikiDev" group.
> To post to this group, send email to tiddly...@googlegroups.com.
> To unsubscribe from this group, send email to
> tiddlywikide...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/tiddlywikidev?hl=en.
>

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[neandr]

With my project I have successfully used jQuery.twFile.js to read some
different text files (prefs.js and some ICS data files). It has to
work (mainly) on Firefox.
John Murphy recommendation looks great to me not to have the security
warning, so I changed the driver list entries to:
driverList: ["javaLiveConnect", "activeX", "mozilla", "tiddlySaver" ]

But unfortunately it doesn't work for me.
Any suggestion about it?

Günter

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100914
Firefox/3.6.10

[neandr]

Just one additional observation:
The file to read from is:
>>> filePath
"/media/wData/_Mozilla/FX_gW/Profiles/myprofile/prefs.js"

Tracing to
972 loadFile: function(filePath) {
973 var r;
974 var content = [];
975 try {
976 r = new java.io.BufferedReader(new
java.io.FileReader(javaUrlToFilename(filePath)));

shows line 976 fails.
I'm on Linux! Is the filePath wrong?

[John Murphy]

Suggestions:

- break up line 976 to determine exactly what is failing (BufferedReader? FileReader? javaUrlToFilename?)

- try from Opera for Linux w/ LiveConnect (if it works, the problem is with Firefox)

- make sure your version of FIrefox supports JavaLiveConnect (some versions removed support)

- make sure you're using the right version of Java (Java 6 update 12)

quoting https://developer.mozilla.org/en/LiveConnect:

While the bloated LiveConnect code in the Mozilla source will be removed (in version 1.9.2 of the platform, see bug 442399), its former API has been restored (see also the specification and this thread) (building on NPAPI?), and as of Java 6 update 12, extensions as well as applets can make use of this restored API.

Also one wild guess: is there a problem with the prefs.js file permissions that is specific to JavaLiveConnect in FireFox?

Hope that helps~ FireFox's spotty support for JavaLiveConnect may be a good argument to keep it later in the driver list...

John

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To post to this group, send email to tiddly...@googlegroups.com.
To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.

--
www.leftium.com

[John-Kim Murphy]

Reviving an old thread; I thought of some ways to reduce/mitigate the cost of calling $.twFile.load() to check if twFile is ready:

1. Add an optional argument to $.twFile.load() that limits how many bytes are read.

2. Move the check to inside the twFile methods: have $.twFile.load()/save() retry for a few seconds before failing. (Not sure if the JS threading model makes this feasible.)

3. Cache the results of the $.twFile.load() when checking. There is a high chance document.location will be loaded, anyways: just return the cached results the first time.

4. $.twFile.save() a small file instead of trying to load() document.path. (Is there any way to delete this file, then?)

5. Are there any small files that are guaranteed to exist and be readable on all browsers/systems? I chose document.location because it should always exist.  

Which method looks the best? Any other ideas?

[John-Kim Murphy]

I got some more ideas about how to eliminate the twFile-not-ready-before-all-document.ready()-handlers-processed limitation:

A. Seems like a perfect application of jQuery's Deferred Object. (Requires jQuery 1.5+)

B. The tiddlySaver driver is the only driver that needs to process anything inside document.ready(). Its deferredInit() just appends the TiddlySaver.jar <applet>. The <applet> could be appended on the first call to a twFile method.

[John-Kim Murphy]

I patched twFile.js so there is a callback that guarantees twFile is fully initialized. It doesn't need to load any files at all. Use like this:

$.twFile.initialize().then(function() {
      alert('twFile is ready!');
});

Accomplished via jQuery Deferrred objects (requires v1.5+).

Patch file attached; full twFile.js file at: http://jsbin.com/adehi5/edit

[Martin Budden]

This does indeed look like a good application of jQuery's Deferred
object. Also an excellent reason to upgrade TiddlyWiki to the latest
version of jQuery.

I'll get your patch plus the latest jQuery into the next alpha.

Martin

On May 8, 7:32 am, John-Kim Murphy <left...@gmail.com> wrote:
> I patched twFile.js so there is a callback that guarantees twFile is fully
> initialized. It doesn't need to load any files at all. Use like this:
>
> $.twFile.initialize().then(function() {
>       alert('twFile is ready!');
>
> });
>

> Accomplished via jQuery Deferrred objects<http://intridea.com/2011/2/8/fun-with-jquery-deferred>(requires v1.5+).

>
> Patch file attached; full twFile.js file at:http://jsbin.com/adehi5/edit
>

>  twfile_add_initialize_method.patch
> < 1KViewDownload

[John-Kim Murphy]

Cool~

I made an additional change that adds a microscopic delay. Otherwise IE fails to load TiddlyWiki for some reason :

-    dfd.resolve();

+    setTimeout(dfd.resolve, 0);

Only needed if changing the driver order to prefer TiddlySaver. I prefer the TiddlySaver driver because there are fewer security dialogs (see previous posts in thread).

Patch attached, including changes to enable TiddlyWiki in IE and Mozilla, as well. View the full twfile.js file at: http://jsbin.com/adehi5/3/edit

John

[Martin Budden]

Yes, I've noticed this IE issue before.

Thanks for the updated patch.

Martin

>  twfile_add_initialize_method_prefer_tiddlysaver.patch
> 2KViewDownload