Javascript script changes not being picked up, need to restart fusion

[Anonymous]

If I create a script, make a change, then run it, the change isn't being picked up.  Do you need to tell Fusion 360 that something changed?

I would swear that this worked a few days ago, before I installed OSX 10.10.2, but it's clearly not picking up changes now.

It's easily repro'ed by just creating default js script and changing the text that's displayed in the example dialog box.

Screencast at https://screencast.autodesk.com/main/details/ae22907c-b3c7-45b8-bc85-4d1ca8622703

Fusion 360 2.0.1407.

[KrisKaplan]

We are using the platform's webkit browser component to host these API scripts.  And it does appear that at least with that version it is not considering the file's timestamp when loading a file URN in its cache control.  I've filed an issue to see if we can clear the cache for these site files before hosting an API script.

But in the meantime, there is a fairly common trick to force the reload of files from html, and that is to add (or change the value of) an unused querystring argument in the 'src' URL.  For example:

<script src="myscript.js?1"/>

If you edit the script, change the '?1' to '?2' to force the script to be loaded new.  (And of course, rev that number on every new edit as necessary.)

Kris

[Anonymous]

Normally when you're doing that kind of update-the-query-string-to-get-around-a-cache, you have a server that can update it for you.  Trying to do it manually sounds really painful.

You can get something similar with shell commands:

fswatch -r -o /Users/james/workspace/jsexperiment | parallel -L0 -j1 sh -x update.sh

And in update.sh, I put a sed command that updates a query string starting with qdate:

sed -itmp -e "s/qdate=[0-9]*/qdate=`date +%s`/" "/Users/james/Library/Application Support/Autodesk/Autodesk Fusion 360/API/Scripts/buildTSlot/buildTSlot.html"

So the entries end up getting changed, every time anything in/Users/james/workspace/jsexperiment changes, to something like 

    <script charset="UTF-8" src="/Users/james/workspace/jsexperiment/html/buildTSlot.js?qdate=1422688753" type="text/javascript"></script>

(Nothing special about "qdate", it's just the first thing my fingers typed)

[Anonymous]

It's turning out to not be that simple, unfortunately. The problem is that source maps reference file names of actual code files without these parameters, and those files aren't getting reloaded either. It's not so trivial to go around the source maps adding parameters to those file urls.

[KrisKaplan]

This appears to be a 'change' in the WebKit behavior in 10.10.2, and similar behavior changes can be seen on that version with Safari 8.0.3.  At this time we are still looking at what our options are, or if this is a defect in WebKit.

Another option is to completely flush the browser cache between edits to force the browser to reload all files.  You can do this by deleting the '$TMPDIR/Autodesk/BrowserCache' folder.  FYI: This same browser cache folder is used for all browser hosted content in Fusion, such as the data panel, so clearing it will cause a complete reload of all of that content as well (but I wouldn't expect this to be much of a concern).

Kris

[Anonymous]

Removing that directory doesn't cause a reload for me.  Once it's in memory, it looks like you're never even trying to load the files again.  

It's not that it's looking at the cache and deciding that the version it has is fresh - it's that it's never looking at all.  You can see this by serving the scripts off an actual html server and watching the logs; if you edit the script tags inside the html file to add a different parameter, you won't see a request for the URL with the new parameter.  You'll see it with the old one.

Interestingly, though, if the script is served by an http server, and it has a sourceMappingURL defined, you will see a new GET request for that map file when you run the script again.  It won't request the script itself, just the map file.

[KrisKaplan]

Yes.  I should have known better.  The cache is held in memory, so deleting the persisted cache would only affect behavior after a restart of Fusion.

If the html file is not being re-read, then we don't have much of an option to work around this, and will have to wait for a fix in WebKit or a workaround in Fusion to dump the cache or modify cache control for these script host browser instances.  But I wonder if a meta tag in the html would disable the caching.

<META HTTP-EQUIV="EXPIRES" CONTENT="0">

or

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">

(Forry for not trying these suggestions.  I'm not the developer working on this and don't have easy access to an environment that reproduces this.)

Kris

[Anonymous]

No, tried both of those.

I also tried just loading the script dynamically (open the file and eval the contents), but eval() of a string containing a lot of javascript is too slow to use (I let it run for half an hour or so and gave up).

Unfortunately, it looks like scripting in the current release is dead.  I'm really hoping there's a new release that fixes this quickly; loosing this feature is painful.

[Anonymous]

the workaround I use for now is like this
1) rename the original script in "Scripts Manager" (the old one is no longer visible)
2) do the changes the way you wishes
3) go back to the "Scripts Manager" and run your new version

[Anonymous]

Even on Windows (where it doesn't have this particular bug), I gave up.  Fusion 360 crashes while using scripts (even the trivial stuff I've been doing) so often I just went on to other projects, hoping the next release will be usable.

[zhijie.li]

I have tried your solution on my machine. It works fine. Maybe you can try it again. The Script in my machine:

testCache.html:

<!DOCTYPE html><html>
<head>
<META http-equiv=Pragma content=no-cache>
<META http-equiv=Cache-Control content=no-cache>
<META http-equiv=Expires content=0>
<script type="text/javascript" charset="UTF-8" src="testCache.js?qdate=1425090997"></script>
</head>
<body></body></html>

update.sh:

sed -itmp -e "s/qdate=[0-9]*/qdate=`date +%s`/" /Users/api/Library/Application\ Support/Autodesk/Autodesk\ Fusion\ 360/API/Scripts/testCache/testCache.html

shell command:

fswatch -r -o /Users/api/Library/Application\ Support/Autodesk/Autodesk\ Fusion\ 360/API/Scripts/testCache/testCache.js | parallel -L0 -j1 sh -x update.sh

[Anonymous]

So what's the status of scripting?  I went back to playing with Fusion today, and it still has the terrible behavior, weeks after this was reported and after a couple updates.  Is it just me?  Should I reinstall, or do something else?

[KrisKaplan]

No.  It is not just you.  We have not been able to identify a workaround to this WebKit local file caching regression on our side that affects Mac 10.10.2 and later (and the equivalent regression in Safari).  We have a bug report filed with Apple, but so far have not heard any timeline for resolution or any possible workaround on our side.  At this time, we only have the workarounds mentioned previously in this thread.  Sorry for the inconvenience.

Kris

[Anonymous]

I'd feel bad about that, but a) I've got a Windows machine lying around that I can experiment on, and b) scripts crash so often in Windows that you end up restarting Fusion on every run of a script anyway.  Platform parity the hard way :-).

[Anonymous]

Has Autodesk decided to end support for scripts on Macs?  I'm really suprised you've let this bug linger for months without a fix.  (And no, waiting for Apple isn't a reasonable decision.)

[KrisKaplan]

Definitely not.  This issue has been assigned the highest priority.  We have identified this as a regression in support with Apple's WebView, and escalated priority support with Apple.  Unfortunately, so far the response has officially been 'there is no workaround for this issue at this time'.

We have explored several workarounds on our side (e.g. JS injection, or attempting various edits of the tags in scripts automatically before running), but none have been robust or side effect free to not be worse than the symptom.  We haven't, and won't stop considering alternatives, but so far the 'right' solution appears to be that we need this regression fixed by Apple, and we will keep up the pressure there.

Kris

[Anonymous]

(Didn't mean to submit this - wasn't done, and I don't see a 'remove post' anywhere...)

[Anonymous]

So I just tried this again, and it's still not fixed.  

Presumably Autodesk now realizes that Apple does not consider this to be a bug, right?  And you have to fix this yourselves?

[KrisKaplan]

Unfortunately, the situation hasn't changed yet.  Apple has accepted and confirmed that this is a bug.  We have an open report case with them, but still no update (I'll make sure we request another update).  This is a regression in the WebKit implementation around local file caching, and as confirmed by Apple, there is no known workaround on the client side for the problem, so we cannot truly fix this ourselves and the workarounds we explored had other unpleasant side effects / risks.

Kris