Error when viewing card changes

Support Ticket

+status
answered
+tags
 

Was editing a card (think I deleted a word), did a save, and all of the card's contents were suddenly gone. When I try to see the change history, I get a Ruby error (will retype below; also have screen shot which I can enter if I ever get an account--applied for one but haven't gotten a response yet, and my login for our site doesn't seem to work here). Now the contents are gone. Would like them back if possible. This happened around 18:40 PST using Safari 4.0.4 on Mac OS X 10.6.2 on docs.cytobank.org. The card is at Getting a copy of U937 data

RuntimeError in

Showing app/views/card/changes.rhtml where line #9 was raised: 

Called id for nil, which would mistakenly be 4 -- if you really wanted the id of nil, use object_id

 

Our sys admin recovered our data for us. For what it's worth, the edit I had made was deleting a line of text. It's possible that I accidentally clicked on the "Delete [this card]" button instead of the "Save" button when I finished editing; however, I still should have been able to view the change history.


Since then, I've found that if I double-click to highlight a word and try to delete that word using the backspace button, it's interpreted as trying to delete the card. This is still on Safari. Has anyone else run into this? Is there a workaround?

  --jldavis94.....Thu Jan 21 21:33:23 -0800 2010


Oh, I think what's happening is a known bug:Double-click triggering edit mode redundantly. When you double-click in an editor, it can trigger the same response as double-clicking normal text: go to edit mode. So it reloads the last version, essentially deleting your work. Is that the behavior?

 

There is not a great workaround yet, although I'm curious as to why your revision history is breaking. I looked at the card and it appears to be working now. Have you been seeing more of those broken revisions?

 

In the long-term we want:

1. to fix the double-click-in-editor bug, of course. it's very annoying, I know.

2. to be able to turn off double-click editing altogether

3. to be able to recover lost data more reliably via changes.

 

not sure what the shortest route is to a workable solution, but if you were able to reproduce the revision-breaking issue, we could weigh the 3. I hope we'll be able to tackle 1 & 2 soon regardless.

 

Thanks for the support tickets. We're working to be more prompt in our replies -- sorry about the wait.

  --Ethan McCutchen.....Tue Feb 16 12:18:25 -0800 2010