JHotDraw will not save in Sandbox

I thought I had this working, but...

I'm trying to identify a problem in an client's system, so I installed JQueryPlugin & EditChapterPlugin as I didn't have those in my test Foswiki site - it also installed ZonePlugin automatically, so I imagine the edit chapter depends on that.

I have a simple test topic in Sandbox with a DRAWING variable. I click click & invoke the Java applet, but it will not exit & save. However, if I edit the JHotDrawPlugin topic in System I can modify either of the test drawings & save them without problems.

I've struggled through the strikeone issues before & the upgrade form 1.0.8 to 1.0.9

I can't understand why it works in one web & not another. Is it permissions?

My client's problem is that simply invoking the drawing asks for an extra authentication (which they cannot get to accept any login), which sounds like permissions too, though knowing my uck it's probably totally unrelated.

-- ChrisHogan - 26 Mar 2010

In Firefox, are there any javascript errors in the error console? Tools->Error Console

Most importantly, does the skin that you use incorporate the BehaviourContrib javascript?

In the HTML on the page where the applet fires up ( /bin/rest/JHotDrawPlugin... ) look to see if you get the script tags roughly in this order (jhotdraw.js should be last):

<script type="text/javascript" src="/pub/System/BehaviourContrib/behaviour.compressed.js"></script>

...

<script type="text/javascript" src="/foswiki-release/pub/System/JavascriptFiles/strikeone.js"></script>

...

<script type="text/javascript" src="/foswiki-release/pub/System/JHotDrawPlugin/jhotdraw.js"></script>

JHotDrawPlugin depends on certain javascript files but doesn't specify this in the code: it just magically turns out on most people's systems' in the correct order. I wonder if you are unlucky enough to get jhotdraw.js loaded too early.

The following patch is probably necessary

Index: JHotDrawPlugin.pm
===================================================================
--- JHotDrawPlugin.pm   (revision 7054)
+++ JHotDrawPlugin.pm   (working copy)
@@ -199,7 +199,7 @@
     }
     Foswiki::Func::setPreferencesValue('DRAWINGNAME', $drawing);
     my $src = (DEBUG) ? '_src' : '';
-    Foswiki::Func::addToHEAD( 'JHOTDRAWPLUGIN', <<"JS", 'JHOTDRAWPLUGIN::DEPS');
+    Foswiki::Func::addToHEAD( 'JHOTDRAWPLUGIN', <<"JS", 'JHOTDRAWPLUGIN::DEPS,BEHAVIOURCONTRIB,FOSWIKI STRIKE ONE');
 <script type="text/javascript" src="$Foswiki::cfg{PubUrlPath}/$Foswiki::cfg{SystemWebName}/JHotDrawPlugin/jhotdraw$src.js"></script>
 JS

If you don't know how to apply a patch, try replacing your lib/Foswiki/Plugins/JHotDrawPlugin.pm with the attached version

-- PaulHarvey - 04 Apr 2010

• JHotDrawPlugin.pm: JHotDrawPlugin.pm

I've a cuple of these sort of messages in the error console:

Warning: Error in parsing value for 'filter'. Declaration dropped.
Source File: http://foswiki.trythisout.co.uk/bin/rest/JHotDrawPlugin/edit?topic=Sandbox.TestTopic;drawing=test
Line: 1

I was comparing my code to my client's & I did have the 3 scripts in the order you specify, but now the hotdraw is loaded second, after behaviour & before strikeone. Adding the edit chapter plug-in seems to have had the effect of knocking the load order out of its original sequence. That or something else in the changes I made to bring my version into line with theirs.

And despite my client taking the default settings & telling me that strikeone is enabled, I can't find a call to it in the code for their page.

I'll make the change to my site & make sure that clears up the situation. If it does, I'll ship them the fix & see if that cures their problem too.

-- ChrisHogan - 07 Apr 2010

Well that corrected the sequence of JS calls, but no joy. I can exit if I haven't changed the drawing, but if I save first then I can't exit. Nothing appears in the error console while clicking save & exit. The only way out is to use the back button in the browser & then, of course, no changes are saved to the drawing.

But when loading the applet I get

Http channel implementation doesn't support nsIUploadChannel2. An extension has supplied a non-functionalhttp protocol handler. This will break behavior and in future releases not work at all.

and

Error: document.mhdapp.readyToSave is not a function
Source File: http://foswiki.trythisout.co.uk/pub/System/JHotDrawPlugin/jhotdraw.js
Line: 3

-- ChrisHogan - 07 Apr 2010

I'm no guru on these things, but it sounds like a bad java plugin. What browser is it? Can you try a different one? On a completely different PC?

It seems the <applet> is not being run, and the foswiki support javascript is not seeing the document elements it's expecting.

-- PaulHarvey - 07 Apr 2010

You're right! I was using Firefox 3.6.3 9my default browser). If I use IE 7 I get a button, not a text link, and the applet exits perfectly.

Which gets me around my immediate problem, but (a) it doesn't help my client (though it might let me debug it a bit more) and (b) I guess that's a bug in the plugin?

-- ChrisHogan - 09 Apr 2010

This plugin works for many users using standard configuration and up-to-date browser/java runtime environments. Foswiki does not have sufficient resources to develop the JHotDraw java code itself, and even if we did we can't realistically support every non-current JVM in the wild.

So to start with, upgrade the client's JVM, and consider re-installing Firefox or at least testing that other java applet software work correctly.

There is interest in offering the latest version of JHotDraw in parallel to the existing one Tasks.Item8305 - the problem of course is that the old .draw files are not compatible with the newest JHotDraw. There doesn't seem to be a reasonable upgrade path being offered by the JHotDraw folks to migrate existing .draw files to SVG.

If you work on debugging this further, we'd be happy to offer assistance where possible. Most devs are avaiable on the IRC channel.

Something that does occur to me, browsing the code - the JS tries to execute immediately - might be worth delaying it until the whole document (incl. java applet) is ready - try wrapping it in something like jQuery(window).load(function () { .... });

-- PaulHarvey - 11 Apr 2010

What puzzles me is that this is the latest Firefox & JVM and that TWikiDrawPlugin (we have a TWiki & Foswiki installation on the same server) works fine with this combination.

Given that this is to debug my client's problems (I've reported their issues as Question469), then we don't have a legacy of old Foswiki drawings. My client has been reduced to attaching images drawn in some PC package because they haven't been able to use JHotDraw at all. I'd happliy have a go with the new version to see what it does & report back.

In the meanwhile, I'll also have a go with your suggestion of the Jquery call

-- ChrisHogan - 20 Apr 2010

Chances are this is a result of not having strikeone enabled.

-- CrawfordCurrie - 13 Jul 2010