Item9408: Wysiwyg Edit latency improvement

I was testing Wysiwyg on my test server sitting at work.

This means that I has a realistic client/server connection instead of the one most of us devs have at home with less speed and more delay.

When you hit the edit button and Wysiwyg starts this happens.

• A normal edit window is visble for a few seconds. Below this windows you can see the help text that is normally hidden behind a twisty at the top.
• After 1-2 seconds the edit window changes to the Wysiwyg editor with the buttons at the top and a split second later the help text is hidden.
• After another second the topic content is visible in the Wysiwyg window.

This is new. We have always had the delay with the normal edit window. But I feel it got worse.

And for sure the help text below which is shown for 1-2 seconds makes the whole experience very dramatic, and very amateur looking.

It seems the new way of hiding the help depends on some Javascript to be loaded and working. We need that text hidden by traditional HTML comment or similar. That flickering and jumping of the whole browser area looks faulty and unstable.

-- KennethLavrsen - 29 Jul 2010

I wonder if this is related to TwistyPlugin changes. I agree that the initial state should be rendered in-line so we're not dependent on external CSS and JS.

May I ask if you are using {OptimizePageLayout} 1=, or defaults? Also, does this happen every time or just when the browser's cache is empty?

I may have to set up low-Q bandwidth simulation to reproduce

-- PaulHarvey - 30 Jul 2010

{OptimizePageLayout} is enabled.

It happens every time.

You can use my merlin.lavrsen.dk to test. Just register and test. It can be broken from time to time and you may need me to update it as I currently do not run a cron to update.

If this is the result of Twisty update then maybe we also see twisties in general flicker? I need to try that also.

-- KennethLavrsen - 30 Jul 2010

Registered and tested, thankyou.

Additionally - being a svn checkout, the browser is getting non-minified JS sources, which for tiny_mce_jquery_src.js are circa 330KiB. Gzip'd minified version is ~48KiB, to compare

-- PaulHarvey - 30 Jul 2010

I wonder if in this case we should de-optimize the page layout - or somehow force the browser to not render until the Javascript is complete. I encountered one instance where I actually started editing on the TML edit box, not realizing that the TMCE editor was still "in flight". When .js finally caught up and overlayed the TMCE editor onto the page it was a surprise.

-- GeorgeClark - 01 Aug 2010

I think depending on JS to do your page layout is a fundamental mistake. We just need to stop relying on JS for layout.

-- PaulHarvey - 02 Aug 2010

Will not be able to get to this until after 14 Aug. Maybe a beta release is doable with this left unfixed if it's mentioned in the known issues.

-- PaulHarvey - 03 Aug 2010

The core reason for the initial bug report is already addressed and is a duplicate of Item9422.

However, there is still a large UI latency that we can get rid of without too much effort.

Hitting edit starts a chain of events:

1. Render edit screen
2. Browser must parse it and start loading up <script src="...> js
3. Eventually TinyMCE is loaded
4. Eventually FoswikiTiny starts an AJAX call to get a HTML version of the TML that TinyMCE can edit
5. Eventually the rest script answers back and TinyMCE completes its setContent

I want to have a go at fixing Wysiwyg + TinyMCEPlugin so that the last two steps are not necessary. It shouldn't be too hard. We do this by getting the edit script (template) to emit both the TML topic text and the TML2HTML version.

My initial feeling is that of 2-4 seconds (on my wiki, assuming primed browser cache) it takes to go from edit-click to editor-ready this could improve latency by at least a second, which is interesting to me...

I'm going to come up with a patch probably by 22 Aug (I am too busy this week and next) regardless of whether we feel it's appropriate this late in 1.1. I won't commit unless MichaelTempest, CrawfordCurrie, KennethLavrsen thinks it's worth it (after reviewing a patch).

-- PaulHarvey - 04 Aug 2010

This sounds like a great idea.

IIRC, Foswiki does a TML2HTML when you click edit (to see if the topic can be converted to HTML, because that was not always possible) and then throws the "editable" HTML away. Foswiki is already doing that conversion - so it "just" needs to go into the edit template.

Please consider the implications for using trunk's TMCE and wysiwyg on 1.0.x? I am not sure what they are.

-- MichaelTempest - 07 Aug 2010

I do not know how this important bug got from urgent to enhancement. It is an ugly behaviour that I never ever want to present to my end users. It is the twisty issue that is the problem. It is Ok that you have to wait a second or two while the editor loads. The problem I reported is the problem with the help text that is shown for up to several seconds and then goes away. This is what needs to be resolved.

-- KennethLavrsen - 09 Aug 2010

Kenneth, the point about the twisty being slow is already identified in Item9422. How are these two tasks supposed to be different?

I would have closed this bug as a duplicate otherwise, but instead took the opportunity to do an enhancement to further speed up the edit screen.

I will leave as urgent as you wish, but I think the priority issue in this task is already identified in Item9422

-- PaulHarvey - 10 Aug 2010

With twisty problem fixed I lower the priority of this one to normal.

The current performance is not a show stopper for 1.1 as it requires rediculous large topics to see the lag in cursor movement.

But for sure feel free to fix it. Normal vs urgent does not prevent fixing

-- KennethLavrsen - 19 Aug 2010

Don't see any significant problems with performance now.

-- Main.CrawfordCurrie - 24 Mar 2017 - 12:11

Commenting is disabled while not logged in