[4346] Textarea not saved

Started by Enc0der, March 27, 2011, 03:10:47 PM

Previous topic - Next topic

Enc0der

Original thread: http://www.simplemachines.org/community/index.php?topic=374577.0

QuoteThe thing is, that you could after you had written something in this text box ( where you are/I'm posting right now ) accidentally push some other button and then be able to use the "go back" in the web browser and the text you had written would still be there, it does seem to work in IE8, but its not working in FF. Its with RC2 and RC3 its not working (tested it in out of the box installations) but does work in RC1. It's currently not saving what you have written here on SMF forums (use FF and test it, "new topic" write something in the text area, press either a link and then backwards, or press backwards in the browser and then forward)
The Subject text area is saved , and so is if you enable quick reply in RC3, but not these big post text areas.

Any updates with this issue?
I'm using RC5 and this annoying problem still exists.


Thank you.

Arantor

I should note that it doesn't happen in Chrome either, so the question then becomes which version of Firefox is it in?

searchgr


Joker™

Browser - FF4
Test site - SMF community (This post :P).


- In quick reply area if you wrote some text and accidentally click back button, when you come back on the page text is still there.
- In normal reply area if you wrote some text and accidentally click back button, when you come back on the page text is not there.
Github Profile
Android apps
Medium

How to enable Post Moderation

"For the wise man looks into space and he knows there is no limited dimensions." - Laozi

All support seeking PM's get microwaved

Enc0der

This is also relevant for FF 3.6.6

Enc0der


Antechinus


Enc0der


Antechinus

Yeah it happens. Probably wont be fixed for 2.0 as it's not a big drama. I use FF4 as my default browser and if I'm worried about a post I just Ctrl+A > Ctrl+C beofe hitting the submit button. That way if the thing screws up I just Ctrl+V once I'm back to the reply page and the post is good to go again.

Arantor

And how many of your users would know to do that, exactly?

Antechinus

Oh hell, I dunno. Probably anyone who has ever copy/pasted text online. Anyone who has taken the trouble to install Firefox is likely to be someone who has some basic computer skills.

Arantor

Unless it's been installed for them, for example. You cannot assume your users are as technical as you are.

Antechinus

I'm not assuming they're as technical as I am. I'm assuming that they know, or can easily learn, how to copy/paste text.

SlammedDime

Does this occur with the WYSIWYG editor, plain text, or both?
SlammedDime
Former Lead Customizer
BitBucket Projects
GeekStorage.com Hosting
                      My Mods
SimpleSEF
Ajax Quick Reply
Sitemap
more...
                     

Antechinus

I know it happens with the plain text editor. Always has with Firefox, even on 1.1.x or on other non-SMF sites. I've just got used to it ages ago so never really worry about it. It'd be nice to have a fix at some point, but it's definitely not worth delaying 2.0 over this.

ETA: Doesn't seem to happen with the wysiwyg (judging by a very brief test).

Enc0der

#15
Quote from: Antechinus on June 04, 2011, 08:17:54 AM
as it's not a big drama.
Yes, it is.. :-\

Quote from: Antechinus on June 04, 2011, 08:17:54 AM
if I'm worried about a post I just Ctrl+A > Ctrl+C beofe hitting the submit button. That way if the thing screws up I just Ctrl+V once I'm back to the reply page and the post is good to go again.
So, you're expecting users to always Ctrl+A->Ctrl+C their messages before hitting the submit button? And what if they move back and forth between tabs when making a long post, and then accidentally click the 'back' button, or a random link in the page, or a random button from the browser's bookmarks tab?
Maybe you'll then tell them to Ctrl+A>Ctrl+C their entire message every few seconds just to be on the safe side?

I actually have a small firefox addon called "Lazarus" that is used exactly for this - automatically saving my forms as I type.
However, this is still a major (or at least, not "minor") bug in SMF for most users, IMHO.

searchgr

This is a major bug ......... !!!!!!!!!!

Antechinus

It's a minor bug, which we'll look at fixing for 2.1. As I mentioned earlier, it was not worth delaying the release of 2.0 for this.

rawlogic

#18
Summary

I was able to recreate this with SMF 2.0 final and Firefox 3, 5, 6, and 7 beta. I didn't test on 4, since you already said it happens there.

Technically, the textarea is saved in Firefox (confirmed that it's in session.js), however, it's not restored. It's a bug in Firefox. I've decided it's a bug because IE has the expected behavior, but Firefox does not.

Firefox normally tries to restore your data when you click Refresh (or Back and then Forward). However, for some reason, Firefox does not restore text for dynamically created (JavaScript) form elements. Again, IE does.

This does not in itself cause the issue, since the textarea in SMF is not dynamically created. However, there's a further bug in Firefox. Firefox will also not restore a static form element that appears after (positional wise) a dynamically created saveable form element (select, texarea, input).

All of the rich text controls are created dynamically and placed before the text area. It's the select boxes (Font, and Color) that cause Firefox to not be able to restore the text area.

Recreating the bug

Here is blank test code to illustrate the bug in Firefox.

This first test illustrates that only the static text area (the wider one) is restored after you click Refresh, but not the dynamic one. Type text into both boxes and click refresh to see.
<html>
  <body>
    Success
    <div id="container1"></div>
    <textarea cols="40" id="static" name="static"></textarea>
    <div id="container2"></div>
    <script>
      var txtArea = document.createElement("textarea");
  txtArea.cols = "20";
  txtArea.id = "dynamic";
  txtArea.name = "dynamic";
      document.getElementById("container2").appendChild(txtArea);
    </script>
  </body>
</html>


This test illustrates that if the dynamically created form appears before the static one, then even the static one won't restore. Type text into both boxes and click refresh to see:
<html>
  <body>
    Failure
    <div id="container1"></div>
    <textarea cols="40" id="static" name="static"></textarea>
    <div id="container2"></div>
    <script>
      var txtArea = document.createElement("textarea");
  txtArea.cols = "20";
  txtArea.id = "dynamic";
  txtArea.name = "dynamic";
      document.getElementById("container1").appendChild(txtArea);
    </script>
  </body>
</html>


Firefox fails in both cases, and worse in the second case. IE will restore the text in both textareas in both test cases. Also, strangely, if you were to close Firefox with a Save and Exit, the session restore feature would restore the dynamic text areas just fine.

Also note that if you disable JavaScript in Firefox, the issue goes away, though you don't get the rich edit box.

Solutions/Work Arounds

Possibly the simplest solution would be (for Firefox browsers only perhaps), to put the Font and Color selection elements to the right of the static textarea. I've tested this solution, and it works.

If the entire form were to be created statically (via PHP) instead of via JavaScript, it wold work in Firefox. I've already tested this, and it works.

We could store, in the session, whether JavaScript is enabled. Then, when the user clicks Reply, New Topic, etc., we use that setting and render the form accordingly, instead of using JavaScript to render the form.

Since only dynamic saveable form elements coming before the static textarea inflict the bug, you could do this just for the Font and Color selection boxes. Note that if you remove the Font and Color selection boxes entirely, the issue also goes away.

Alternatively, we could always just render all of the controls all the time, and display a warning for folks without JavaScript (hopefully the minority) why their buttons don't work.

Have Firefox fix the bug

Any volunteers to submit this bug to Firefox? Note that it's related to bug 487657.

Also, if someone is familiar with Firefox source code, perhaps you could root around and find an easier work around.

Antechinus

Well spotted. Thanks. With a bit of luck Mozilla will sort this one before we have to sort it for 2.1. ;)

Advertisement: