Safari/MT Bug Reduction
posted on october 29, 2003, tag: software
As promised, I looked into the Safari/MT bug I reported earlier, and I think I've found the problem. It seems to be due to Safari's over-caching, which several people have complained about in the recent past.
Here's what happens:
Movable Type uses the same name for its textarea on both the Edit Comment page and the Edit Entry page. Both are named "text." When you view the Edit Comment page to delete a comment, Safari caches the text inside that textarea. Then, immediately after clicking the Delete button, MT forwards you to the comment's related entry.
This is where the problem starts. Safari loads the cached comment text into the "text" textarea on the Edit Entry page. How do I know this? Here's a visual example:
You'll notice that the text in that box does not match the text from the same page's source. That's because the cached text appears in the box, even though Safari clearly gets the correct text (I mean, it's in the source for god's sake!). But even though it's in the source, if you hit save, you'll post the text in the actual box to your server, and overwrite your entry.
So the problem is Safari. And it's a cache problem. I've reported a bug to Apple, posted about this on the MT support forums, and trackbacked this (and the last) entry to Dave Hyatt, so hopefully at least someone will fix this in the long run. In the meantime, just be careful if you're a Safari/MT user.
Update: You can find some workarounds for this bug in another entry, Safari/MT Bug Workarounds.
Comments
There are 18 comments, comments are closed
Brandon on 10/30/2003:
I can confirm this as well - I couldn't figure out what the hell was going on and just considered it a MT bug. Thanks for figuring this one out...it was driving me batty.
Boult on 10/30/2003:
never happened to me! Because I use Kung-Log to do posting.. sometime I use Safari to edit mistake but always post in Kung-Log. I even use Kung-Log to edit mistakes. But however, I hope this bug get ironed out anyway!
Garrett on 10/30/2003:
Yeah, I always use Kung-Log to do posting too, but since KL can't delete comments, it's necessary to jump into MT directly to do that. Therefore, even if you use Kung-Log, you might still come across this bug.
jim on 10/30/2003:
was unfortunate to lose a few posting content after i edited their comments and rebuilt immediately without noticing the caching of the comments in the content textarea...nowadays I'll do a refresh after I edited the comments so that the correct info show on the post's content text area before I do a rebuilt.
Paul on 10/30/2003:
I can confirm this, too. The first time it happened, I was seriously concerned that my weblog entry had been replaced by a deleted comment; a refresh took care of it.
Donald on 10/31/2003:
Hey, thanks for shedding some light on this. It's happened to me a couple of times and I thought I was going crazy. Thank God for Google's cache!
jon on 02/16/2004:
One thing I wish they would have in the setting is a "check for new versions of stored pages: [] every visit to the page" like in IE. I think that is a good feature for people using web apps and not wanting to rely on meta headers to dictate refresh: always.
Adriaan on 02/16/2004:
cough ecto cough
Todd Dominey on 02/17/2004:
This "bug" has bitten me more than once. I now post all my weblog content with NetNewsWire instead. Too bad.
sdf on 02/17/2004:
have you tried 1.2?
"Caching Improvements - Safari's WebCore cache was not honoring expiration time, and this led to stale content remaining in the cache. This issue has been addressed."
Garrett on 02/17/2004:
Ecto does not solve this problem. This problem occurs primarily when deleting comments. Does ecto delete comments? If it can, I can't find that option.
And really, Adriaan... do you need to spam advertise for your product here? Everyone in the free world knows about it.
Frankly, I'm not the biggest fan of ecto. I think Kung-log was great, and I think ecto is a misstep. I'm forced to use it now (because Kung-log doesn't work any longer with my system for some unknown reason and ecto does), and every time I use it I realize how much I dislike it compared to Kung-log.
David Hyatt on 02/20/2004:
I don't completely understand this bug. I even use MT for my blog. :) Can you be very precise regarding steps to reproduce so that I can see if I can trigger this bug on my blog? This doesn't sound like a caching problem at all to me... it sounds like a bug with session history and state restoration of form controls, but I need more precise steps to be sure.
David Hyatt on 02/20/2004:
Agh, that's awful! I just reproduced.
Garrett on 02/20/2004:
I'm glad you reproduced it, David. I've been meaning to create a simpler test-case for a long while now, ever since someone else at Apple asked me to do so. It just got put in the to-do list and never got done.
I guess now that you've seen the bug in action you don't need me to create a test case? If you still do, let me know.
(And yes, it is quite awful.)
David Hyatt on 02/20/2004:
I don't think I need a testcase. I think I can just randomly nuke comments from my blog until the bug is fixed. ;)
Garrett on 02/20/2004:
Okay, great. Thanks for taking time to reply here.
I'd love to hear back from you with any progress on the bug, if that's not too much trouble to ask.
Elad Stern on 04/25/2004:
I ran into a textarea related bug on Safari, and its description is slightly different:
You need to switch a page inside a frame (navigate to a new page), where both pages have a textarea element, but with a different text each time. The value of the ID attribute does not matter. The value of the textarea from the previous page remains visible (also via script). View Source shows otherwise.
The solution I found: give the textarea a name attribute, and make sure the name is a different one for each textarea.
减肥 瘦身 on 06/19/2004:
减肥 瘦身