Item5045: Improve handling of network errors

Problem

• Work is lost when there is a network error during save and/or html2tml.
• TinyMCEPlugin should handle network error during tml2html better.

The user sometimes (25s latency + IE6,7 browsers) will see the initial:

Please wait... retrieving page from server.

And the response never comes, the message never goes away.

On a few occasions, I've had users somehow assume that this is a benign thing and that they can continue their work below this message in the editor, and so are surprised that when they save, they have replaced their work (when it's a RepRev). They assumed their previous revision would automatically appear eventually in place of the wait message.

-- PaulHarvey

Scenario:

• Latency > 20s. This might be considered unrealistically huge, but we're not talking average latency here, just once-off: desperately overloaded PCs, PC goes into hibernation, temporary network outages/congestion...
  • in a test environment, use sudo tc qdisc add dev eth0 root netem delay 25000ms
  • Some wireless wan users in marginal coverage areas. Error rates are high, resulting in large (4000ms), highly variable (+/- 10000ms) latency in TCP application layer
  • Badly configured cross-institutional routing policy
• Internet Explorer 6 and 7 (unconfirmed in 8)
  • tinymce.util.XHR.send() - we pass in onSuccess and onError handlers; but these never get called if the request simply takes too long (under Internet Exploder browsers). This bug should be filed upstream.
• user switches to/from raw, or tries to save.

Actual Behaviour:

• "General error" or "timeout error" OR
• (MSIE browsers only): "please wait... retriving page from server" never updates with topic content (onError/onSuccess is never called)

Expected Behaviour:

• Prompt to retry the conversion (html2tml/tml2html), or
• on failure, action is canceled (user's editor state is restored to how it was prior to the save/concert)

Original Comments

When you have a network failure and you push on save, all contents is lost. Using the back doesn't give any info.

In the raw edit mode, it is possible to use the back button and then you have your information back, which you can try to save again or copy to something else.

Wouldn't it be better to make some kind of check if network is ok before saving.

This can be easily reproduced by disconnecting your PC from the network

-- TWiki:Main.FrederikBeun

Was this is Firefox?

There is a known issue with going back in the browser in Firefox - in TinyMCE mode.

-- TWiki:Main.KennethLavrsen - 29 Nov 2007

No it wasn't. It is Internet Explorer version 7

-- TWiki:Main.FrederikBeun - 30 Nov 2007

When you go back, there is a javascript error in the guts of Tiny MCE (something to do with an access violation accessing the document when adding event handlers)

Unfortunately IE doesn't give much information

This does not affect stored data, obviously enough, but large edits can be lost this way.

Corrected the summary line. Only changes are lost.

CC

I cannot reproduce this. Just tested with IE 7:

1. Started an edit with TinyMCE
2. Unplugged the internet cable
3. Clicked Save
4. After a timeout, Explorer gave me the page "Internet Explorer cannot display the webpage"
5. Reconnected the cable
6. The editor window says "Retrieving page from server"
7. ... but it showed my changes as well
8. Saving and all is well

The same happened when going to Preview first and then disconnecting.

-- TWiki:Main.ArthurClemens - 07 Dec 2007

Indeed the solution is you need to go back when the connection is there again, otherwise it shows the Retrieving page from server remark. When network is back and you push then on refresh page, then you loose everything. But if you instead you go back and then forward on the browser you get everything back.

How can we make this clear to the users?

-- TWiki:Main.FrederikBeun - 07 Dec 2007

I don't know. It's not something that is easy to explain.

I am very tempted to set this as "Normal", but I leave it to the release manager's judgmenet (that's why we have release managers, after all:-) )

CC

I am used to in web applications that if you submit to a disconnected network and then hit refresh it is good bye to anything to entered.

But going back and resubmitting should work. If this is the case then there may not even be a bug.

If this does not work then it is the general going back that is broken.

That should be fixed.

But a fix is not within a few days reach so I lower to normal. We can release with this. Especially because TMCE is a plugin that can - AND WILL FOR SURE - be updated many times the next months.

KJL

There is plugin called AutoSavePlugin which automatically saves the topic during editing. It uses AJAX technology to save in the background. Maybe the plugin can provide a simple solution for this item.

-- SvenHess - 23 Jul 2009

I don't lose my work (back button works okay) on Firefox. I note that we have autosave plugin enabled in TMCE by default.

Sven, Thomas - what are your thoughts? What about RepRev behaviour - gee it would be nice for RepRev to automatically save every 20 minutes regardless of how many RepRevs there were

-- PaulHarvey - 21 Oct 2009

This is data loss that could be avoided.

So it should probably be a release blocker, but we've probably had this for a very long time.

I hope to have a fix this week.

Michael and Crawford, I added you to his bug to provide any guidance or input you may have.

My intention is to do a JS prompt dialogue "retry/cancel". "cancel" should apply an "undo" to the editor, so that the user sees the content as it was before we replaced it with "please wait" message.

A better longer term solution would be for there to be a div in the edit template somewhere, instead of doing our error/"please wait" feed back in the editor content.

-- PaulHarvey - 24 Nov 2009

I don't have anything much to add, except to agree this should be a release blocker - but for trunk, not for patch. A retry/cancel prompt would definitely be my preference, if it can be done. It should be possible to analyse the return code from the XHR to generate this.

-- CrawfordCurrie - 24 Nov 2009

I like what you propose, but I do not think this should go into 1.0.8.

-- MichaelTempest - 24 Nov 2009

Ok, so not for 1.0.8, but something should be done for the next release after that, patch or otherwise...

• Submit bug report upstream for lame IE behaviour regarding lack of firing of onError
  • Do some sort of lame setTimeout(30 seconds? wait... retry... cancel) work-around

Just got given a some other work to be done by Friday, so my promise for a fix for this week was a lie.

-- PaulHarvey - 24 Nov 2009

Nobody in the WaitingFor contributed feedback; throwing this back out there. I may get time at some point as I consider this important, but not soon.

-- PaulHarvey - 16 Jan 2010

I see this as depending on Item2297, so this cannot block the release in June.

-- PaulHarvey - 28 Feb 2010

I would rather tackle this in the jquery/refactor for 2.0 than do it twice; if somebody else has time to do this on 1.1, feel free.

-- PaulHarvey - 06 Apr 2010

Since the upgrade to 4.5.3 the network handling has changed radically. I can't see anything here worth saving, so closing it no-action. If network errors recur, a new report should be opened detailing how to reproduce them.

-- Main.CrawfordCurrie - 24 Mar 2017 - 15:40