Spell Checker Problem

Topics: Themes
Feb 10, 2011 at 11:55 PM

Hi folks, installed the TinyMCE spell checker after checking Guy Nethery's post and the post he referenced.

Everything works fine, except that around 1 second after the spell check completes, all the red error lines just disappear.

If you are quick, you get to see the suggested correction list before it also disappears.

Do the check again, red lines flash up and go, do it again and it's nothing - no spell check.

Any body came across this before or have any suggestion as to what may be causing the problem?

Feb 11, 2011 at 6:06 PM

Hey Andy,

Are you in firefox?  I did notice this in Chrome.

Feb 11, 2011 at 7:13 PM

Hi Guy

Tried it in FF, IE, Chrome, Safari and Opera.

I have a heavily customised theme, so I tried it in the standard theme, thinking there might be some obscure interaction going on somewhere, but same.

The thing I did not try was checking from a different computer, it's a long shot, but I'll try that.

Feb 11, 2011 at 7:37 PM

Hi Guy

Just tried it from another machine, still the same.

The same thing happens when I view the site in localhost, you try various configurations but without a starter for ten it's like looking for the proverbial needle in a haystack.

Feb 11, 2011 at 9:29 PM

I am now experiencing the same thing using my office computer.  I will check it out this evening and see if I get this happening at home.  Hopefully it is an easy fix.  If not, maybe the brain powers, developers that is, can pipe in.

Feb 12, 2011 at 4:51 AM

Well....no matter what i did I could not get it to stop disappearing when spell checking a POST.  However it does not happen when spell checking a PAGE.  I also built a page with a new editor window and it works well also.  You can try it here

So the question is, what is happening when authoring a POST that causes the editor to seemingly refresh about ever three seconds.  I honestly have no clue where to start troubleshooting that.  I am hoping that someone more skilled than I might give some input such as BenAmada, rtur, madskristensen or neuromancer

Andy, how about yourself.  Are you a skilled programmer?  I am more of a hack or wannabe but I am learning.

Feb 12, 2011 at 11:37 AM

That's interesting, first port of call would be to check any JavaScript associated with the post editor. As far as programming goes, I understand the basic logic and constructs which are pretty much the same in any language (the accents vary), but DOTNET is new to me and it takes quite a bit of time to become familiar with the classes and libraries in the framework.  

When I get a chance I will poke around in the JavaScript to see what's happening there, a spell checker is pretty much fundamental to the post editor, in my opinion.

Feb 12, 2011 at 1:15 PM

Guy

Curiosity was getting the better of me, I've just had a look at the JavaScript in the Add_entry.aspx.

There is an autosave function, that invokes a DOTNET function called WebForm_DoCallback that causes a refresh, I will investigate this further and find out exactly how everything works.

In the mean time look for the set timeout function within autosave and change it's value up, I've upped mine by a couple of zero's to give the spell checker time to work.

setTimeout("AutoSave()", 500000);

This is just for testing, but it shows this function to be the culprit.

Feb 12, 2011 at 3:01 PM

Guy

I need to be elewhere for a bit, but here's my thoughts so far:

The WebForm_DoCallback function apparently handles the nitty gritty Ajax stuff (data refresh), what we really need to do is somehow detect when the spell checker has been activated and cancel the autosave for that period.

While we're in here as a side issue I'd like to be able to do some tag verification, i.e. add some logic to check existing tags and prevent duplication on entering a new tag, to prevent say Tag being entered when tag or TAG is already listed.

Feb 12, 2011 at 4:03 PM

Excellent work.  I found two instances of setTimeout("AutoSave()", 500000);.  One just below the AutoSave function and the other at the bottom of the page between script tags.  This one seem to be what triggers the AutoSave at page load.

I did this

<!-- <span id="autoSaveLabel" style="display:none;"></span> -->
                            <span id="autoSaveLabel"></span>

This will show the date/time info of each save.  It shows up down by the "cancel" link when viewing the Add_entry.aspx page.  If the setting at the bottom of the page is still 5000 and the other is 50000 then it saves the post data 5 seconds after the page loads and then not again until 50 sec have passed.

I also changed this:

document.getElementById('autoSaveLabel').innerHTML = "Autosaved on " + currentDate + " " + post;

This will show exactly what is being saved.  but it is not saving anything to the database or at least from what I can tell.  What it seems to be doing is just remembering the current status of the data entered, title, text, tags & categories choosen so if you leave the page before saving the post and come back your data is still there.

I eventually just commented out the entire AutoSave function and when I left and came back my entered data was gone.  I had to clear my cache because the data from my previous unsaved post would show. 

Is it possible this is setting some type of cookie or something so you don't accidentally loose your entered data?

Feb 12, 2011 at 6:30 PM

From what I read, the WebForm_DoCallback function is provided as part of the DOTNET script runtime machinery and temporary data storage is managed by that.

In the case of the post editor it looks like the field values are collected at regular intervals and posted off to the server, so in between times, if I'm reading this correctly, the server is storing the data somewhere.

So if you tab away from the post editor and come back, the latest data from the server is used to populate the post fields... I guess.

Definitely a good thing, especially for those longer and carefully crafted posts. The solution to the spell check problem therefore should ideally just stop the data refreshes for the duration of the check.

Coordinator
Feb 13, 2011 at 1:15 AM

You are correct, auto save saves content, if I remember correctly to session variable, so that you don't have to re-type it if accidentally moved to another page without saving.

Feb 13, 2011 at 12:55 PM

Guy

I have tried a few different things to disable autosave when spell checking and it was getting messy, so what I finally settled on was removing all references to setTimeout and calling AutoSave on page exit.

I think it's a good compromise, the spellchecker works and your work is saved if you tab off the post editor (which is the most likely scenario for losing a post in progress).

I added this line just below the document.ready function-> $(window).unload(AutoSave);

$(document).ready(function () {
    $("#uploadImage").colorbox({ width: "550px", inline: true, href: "#uploadImagePanel" });
    $("#uploadVideo").colorbox({ width: "550px", inline: true, href: "#uploadVideoPanel" });
    $("#uploadFile").colorbox({ width: "550px", inline: true, href: "#uploadFilePanel" });
 });
$(window).unload(AutoSave);

If you go for the belt and braces approach, then you could leave setTimeout in, but up the interval to something like a minute or so.

Thanks rtur for confirming info on session var.

Feb 13, 2011 at 7:06 PM

That makes sense but it doesn't seem to be saving.  Example:(I am assuming the trigger at the bottom of the page is still active(setTimeout("AutoSave()", 5000); ))

go to write a new post>  Wait at least 5 seconds before beginning>  create a title and type some message>  click the comments tab> go back to the post tab> click create new post and the previously entered data is not there.  If I page back rather than go back to the post tab> click create new post then the data is still there.

If I get my header and some text entered before the 5 seconds then it is there when I follow the above.

It is a though the AutoSave does not work after someone has chooses to leave the page.  I tried moving $(window).unload(AutoSave); to the very top of the scripts but still no go.  I confirmed the event triggers by creating an alert on page unload and it shows up.

I even tried $(window).unload(SavePost); to see if the post would just save but no go there either.

My be best to leave the belt and braces approach with a setting of 60 seconds or so.   My other thought would be to create an alert that would stop the user from moving on before saving as a draft.   So, it would say cancel to go back and save a draft or OK to move to next page and lose changes.

what are your thoughts?

Feb 13, 2011 at 8:01 PM

OK...got it to work...I think

changed unload event to:

$(window).bind('beforeunload', AutoSave);

Found info for direction here: http://www.mkyong.com/jquery/how-to-stop-a-page-from-exit-or-unload-with-jquery/

Feb 13, 2011 at 8:58 PM

I would try and avoid using beforeunload with jQuery, it's not recommended by jQuery and might not work in all browsers.

You had it working prior to using beforeunload (the alert you put in proves that), but you probably would not notice it, if you leave the setTimeout function inside AutoSave then when you leave the page AutoSave will execute and off you go to the next page, the setTimeout is set to execute after a delay, but you have already left the page.

Say you set the timer to save every minute, it will save every minute but if you leave the page 1 second before the next save, you loose whatever you did in the last 59 seconds. So it's worth depends on how long you spend writing the post.

I took out all the timers associated with AutoSave and it works a treat, it's clean and does the job.

Take out the two instances of setTimeout associated with AutoSave and use the $(window).unload(AutoSave); and then test, it's fairly robust.

The AutoSave at set intervals may be useful for some other unforseen circumstance/interruption, maybe a browser freeze or something like that, in which case you're goosed anyway since that would involve restarting the browser- data gone.

Feb 13, 2011 at 11:01 PM

Guy

Leave this in at the bottom of the page after the closing table tag

<% if (Request.QueryString["id"] == null)

{ %>
     <script type="text/javascript">
         setTimeout(AutoSave, 5000);
     </script>
<% } %>    

Looks like it's needed.      

Feb 14, 2011 at 9:31 AM

One more problem, my fault for not doing enough testing. Saving with page unload saves the field values for every post you open in the editor, it needs to save only for unsaved posts. You will notice this if you open a post for editing and then do a write new post. I will revisit this when I get time, for now I've went back to the original code with timer interval set to 1 minute in the AutoSave function. I'm tempted to put a save as draft button in, but it kind of defeats the purpose of the auto save.

Feb 14, 2011 at 10:42 AM

This is better, but not perfect. Added a check to see if the post was unsaved and moved this to just after the closing script tag of the document.ready stuff

<% if (string.IsNullOrEmpty(Request.QueryString["id"]))
{ %>
                <script type="text/javascript">
                    $(window).unload(AutoSave);                                                               
                </script>           
 <%}%>    

The problem remains that the post editor fields are filled are always filled with your last autosave contents.

This is not always what you want, if you had saved your post and then go to write a new post, you should be presented with a blank form.

So still not quite there yet.

 

Feb 15, 2011 at 1:08 AM

I think I understand why the Request.QueryString["id"] is needed and it makes sense.  I think though I must be doing something incorrect.  I have all the changes made.  To test I follow these steps:

  • go to author a new post
  • Wait 5 seconds to let the first AutoSave happen with no data
  • Write a title and and any text in post body
  • Now navigate away from page:
    • Go go Settings
    • Back to Post
    • Write a new post

In Firefox the data is retained and shows when you go back.  In Explorer and Chrome it does not or at least it is not for me.  If I use the $(window).bind('beforeunload', AutoSave); it does work.  But I agree with you that it is not best practice after doing some reading.

As for the data saving after the submit button has been clicked, perhaps another if statement like if submit button clicked the just exit else move on the the "id" if

I am not sure that can be done but it seems as though it might be a viable solution

Feb 15, 2011 at 2:11 AM

Well spotted, I barged on with testing in FF and you are right - no go in other browsers. Wouldn't it be nice to have the time to have a good run at this without the inconvenience of the daily routine and have the benefit of some DOTNET experience. When I first looked at this I thought the autosave was just an autosave function, it quickly became apparent that it's doing more. As soon as I get time I'm going to look deeper. The spell checker is a must and so is auto saving the drafts. We'll get there and make sure the solution is an elegant one. It's a learning curve, I'll contact you with my email address so we can throw some ideas around.

Feb 15, 2011 at 2:44 AM

to get around the data filling in after the post being saved you did something like:

Create a global variable called savedme = 0;

add to the function SavedPost()...savedme = savedme + 1

now our script below looks like:

 <% if (Request.QueryString["id"] == null)
                       { %>
                    <script type="text/javascript">
                        $(window).unload(AutoSaveOnExit);
                    </script>
                    <% } %>

And we have a new function:

function AutoSaveOnExit() {
                    if (savedme == 0) {
                        //alert("right");
                        AutoSave()


                    }
                    else {
                        //alert("wrong");
                        retrun;
                    }

                }

Seems to work but like I said I am just learning.