So now, if a publish goes awry, or for some other reason you clicked off the posting page, you can hit “back” and everything should be the way you left it.
Interestingly, the fix was different for IE and Firefox. The problem with IE was that we were setting no cache headers on the posting page, so IE would do a reload when you went back to it, restoring the form to its server-pristine state.
Firefox wouldn’t reload, but our JavaScript page creation was confusing its saved form state, so it wouldn’t restore the text right. Now we have even more JavaScript that pushes the contents of
textareas around to placate Firefox’s caching.I can’t find a reference after a few minutes searching, so I’ll describe the issue: Blogger generates the edit post page with a
textarea that is either empty (for a new post) or has the saved post (for editing an old post). The rich text editor boxes (EditHtml and Compose) are created dynamically with JavaScript, using the contents of the textarea for their initial value. Since Firefox bases its form state caching on the order of elements at page-load time, the rich editor boxes haven’t been created yet when Firefox is restoring values, and therefore cannot have their state restored. Instead, they load as normal and base their contents on that textarea, but, since you never edited that textarea, it still has the value it originally got from the server.Our new strategy is to copy the contents from the rich editor boxes back into the
textarea as you navigate away from the edit post page. That way, the textarea gets restored correctly when the page loads, and the rich editor boxes are built using the cached post instead of what originally came from the server.Not sure how Firefox 1.5 will deal with this, given its new caching.
Update: Back button doesn’t work in Safari, which caches the state of the page, and it inadvertently broke posting for Opera. Sorry guys! Fix is on the way.
Update 2: As of 11/11, Opera should be working again, as well as the back button in Safari.
