I’m using Tracks 1.7 on Ubuntu Linux (Hardy Heron) installed with Phusion Passenger in Apache.  I’ve tried using both Internet Explorer 7 and FireFox 3 to modify the tasks that I created using my previously working installation of Tracks.

I am getting some strange behavior when attempting to delete, edit, or star tasks.  I get different behavior for each action.  When attempting to edit tasks, Firefox shows some plain text and IE attempts to download a file called “edit”.  Delete and Star both give me the Tracks specific 404 error in IE, while Delete in FF prints some plaintext XML.

Example of plain text:

While attempting to post this, Tracks briefly reverted to normal behavior, but is back to what I am describing.  I also notice that when ‘broken’, icons light up but do not flash when I mouse over them.  What could cause this sporadic behavior?  I’m no Ruby developer, so I’m not sure how to go about troubleshooting this.  I’ve restarted my server and forced Apache to reload with the same results.  I can create a user for anyone who wants to observe this behavior at http://gtd.grantserver.dyndns.org

I just realized that the icons don’t flash, they just fade when you click them, so ignore the part about flashing.  I think the problem may be on my end, as I am attempting to access my site from behind a proxy that caches pages.  I found that regenerating my token and logging in/out seems to make things work again.

When I logout and back in when not regenerating the token, the strange ‘broken’ behavior begins.  I think this may have something to do with the proxy/cache sitting between my server and this computer.

When javascripts appears in the browser (of in a downloadable file in ie) it means that the javascript in your browser probably has failed or was interrupted before finishing. Of course this could be because an ajax or other javascript call was not working because of your specific setup.

I could be that your cookie is not working through the proxy? If the behavior begins, log out, delete the cookie and try again if this is the problem. The cookie holds the session key.

It seems that the problem is that the browser sees a click on a “file” without an extension.  It is then unsure how to proceed.  It goes into its OS list of file extensions and associations to figure out what to do.  It is still not sure, so it asks the user.  I have tried changing the file associations as far as I was able to do in Windows—trying to remove the option for user confirmation—but also had only temporary luck with it.  This problem occurs in Internet Explorer but not Firefox.  Could there be a server-based solution or fix?

correct. This happens because the click on the url is not handled by Tracks’ javascript in the browser. There is probably an error in your javascript console of your browser…

But I am using Internet Explorer.  It seems as though the application should be designed so that this problem does not occur with common browsers…

I had the same problems albeit on Windows 2003 using IIS 6.

The problem was that the web server was attempting to serve up dynamically generated Javascript files (e.g. /behaviours/projects/14.js) directly from the file system rather than passing them through Ruby to generate them on the fly.

On my system (using Ionic to rewrite URLs and FastCGI) the solution was to create rewrite rules which would pass everything through Ruby except files in folders which actually exist under the public folder. (Yes, FastCGI should be able to do this but that wasn’t working for some reason).

that should be correct. You could narrow the execution to the /app directory though.