search

power-media / prado3

Automatically exported from code.google.com/p/prado3
Other
0 stars 0 forks source link

THtmlArea sometimes not loading properly from callbacks #404

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Clear your browsers cache (preferably also shut it down and restart it to 
avoid any caching)
2. Load the testcase
3. Click the button
4. Watch the editor appearing

What is the expected output? What do you see instead?
A THtmlArea should be loaded and displayed. However, in most cases, if you've 
properly cleared you browser cache, this won't happen and the <textarea> won't 
be transformed to a WYSIWYG editor. If you have not properly cleared your 
cache, and there's already a copy of the editor scripts in it, the WYSIWYG 
editor might appear and display properly.

What version of the product are you using? On what operating system?
Prado/trunk. IE9, FF12, Chrome16.

Please provide any additional information below.
This is caused by tinyMCE itself employing some lazy-loading technique, which, 
however does not really play nicely with AJAX calls. Depending on actual load 
times and other timing factors this might lead to Prado client-side trying to 
instantiate tinyMCE editors at times when no or not all tinyMCE scripts have 
finished loading and/or initialization yet. 

The bug is not exposed when the THtmlArea is instantiated from a normal or a 
postback request, because in this case all Prado scripts on the page are loaded 
and executed synchronously (meaning they block until they finished 
loading/execution). That, however, is not the case when the scripts are loaded 
from a callback request, in which case execution does not happen synchronously 
- therefore sometimes resulting in the above described situtation.

I've attached a fix for this issue which 
1. waits for the tinyMCE scripts to load, and
2. uses the tinyMCE's support for callbacks to delay the actual 
constrcution/transformation of the editor until tinyMCE has completely finished 
loading
thus avoiding the buggy behaviour.

Original issue reported on code.google.com by google...@pcforum.hu on 26 May 2012 at 1:45

Attachments:

GoogleCodeExporter commented 8 years ago 
Thank you. I'm looking forward to commit your patch, but i found a small 
problem related to  the test "if (Prado.WebUI.THtmlArea.tinyMCELoadState==0)" 
at htmlarea.js:61.
The first time a THtmlArea is shown it works correctly, but if it gets hidden 
and shown again, it won't work; i attach a small testcase for this.

Original comment by ctrlal...@gmail.com on 27 May 2012 at 6:35

Attachments:

GoogleCodeExporter commented 8 years ago 
You are right. I forgot to add the line

  Prado.WebUI.THtmlArea.tinyMCELoadState = 255;

to Prado.WebUI.THtmlArea::compressedScriptsLoaded. It needs to be added as the 
first line to said method, and then your testcase will work as expected.

Original comment by google...@pcforum.hu on 27 May 2012 at 9:29

GoogleCodeExporter commented 8 years ago 
Committed as r3148, thank you!

Original comment by ctrlal...@gmail.com on 28 May 2012 at 6:57

GoogleCodeExporter commented 8 years ago 
I had to commit r3157 to fix a regression. THtmlArea was working flawlessy on 
callback, while it was not able to render itself anymore on postback.

Original comment by ctrlal...@gmail.com on 1 Jun 2012 at 8:09

GoogleCodeExporter commented 8 years ago 
This was most likely because you didn't commit my other patch for issue 235, 
which now allows deferring of loading of JavaScript files (including Prado 
scripts) until the end of the rendering phase. 

Please have a look at that (new post at the end of issue 235) and check whether 
the regression is present even if that fix/improvement is also applied!

Original comment by google...@pcforum.hu on 1 Jun 2012 at 4:22

GoogleCodeExporter commented 8 years ago 
Sorry, as usual i didn't notice the comment. r3159 applies your latest patch 
for #235 and reverts r3157

Original comment by ctrlal...@gmail.com on 1 Jun 2012 at 10:38

GoogleCodeExporter commented 8 years ago 
Yeah, was a great idea from Google to remove the Updates summary page from Code 
projects, thus making it impossible to easily track all changes at one place.

Considering migration to GitHub might be worth a thought.

Original comment by google...@pcforum.hu on 1 Jun 2012 at 11:53

GoogleCodeExporter commented 8 years ago 
We already had that idea, but we planned it after the 3.2 release

Original comment by ctrlal...@gmail.com on 2 Jun 2012 at 4:53