Editor has some problem to set custom contentsPreFilters at Chrome

[youngho]

If Editor Plugin has a contentsPreFilters, the pre filter doesn't apply at Chrome.

Looks like there is some loading sequence problem with Chrome.

I attached the test case, and the test results are

FF IE Chrome Safari(windows)
O O X O

[Jared Jurkiewicz]

This is sone sort of timing window issue. If the content has loaded before all the plugins have registered, then the filter is not applied. I can see the content error quite easily:

Chrome: Prefiltering content. test_ContentPrefiltersPlugin.html:34Content loaded!. test_ContentPrefiltersPlugin.html:36Registered my plugin.

Firefox: Registered my plugin. 3 Filter called: <p> jodo </p> <p> DOJO </p> Content loaded!.

Need to understand/see if there is a way to delay setting the content until all plugins have loaded (and thus filters registered.). Looking further.

[Jared Jurkiewicz]

Bill,

Assigning to you for your thoughts. The basic problem is the RichText? widget is instantiated and postCreate() called on it, which in turn does open(), which invokes the load flow of the Editor async, *then* the plugins are iterated over and loaded. Depending on how quick 'open' is, it may finish before the plugins are loaded and thus leading to this issue

One thought I had would be to add a param to RichText? that is a deferred delays the actual setValue() until some external call to it to load it (if the widget was extended), otherwise do nothing. Some sort of optional load deferred to delay setValue until X happens. In this case, the X is loading all the plugins. I'm going to prototype that and see what you think.

-- Jared

[Jared Jurkiewicz]

Fix for load timing issue.

[bill]

Hmm, it seems like the simpler solution is to just run all the preFilters before even calling open(), by moving the this.inherited() call in Editor.postCreate() down. Does that work?

Perhaps the Deferred has some performance benefit but I don't think it's worth thinking about.

[Jared Jurkiewicz]

You can't call prefilters before open. The way a lot of plugin logic works is it assumes the editor has at least had the document created (if not fully loaded), as they may attach events to it and the like. So far the leats infavise fix I can find is the one I already attached, the one that just delays setting the value until all plugin init has completed (and thus all filters installed via plugins have registered).

[Jared Jurkiewicz]

And yes, I did try moving it. That was my first attempt at a fix, actually, because it did seem the 'simpler' one. Unfortunately due to the plugins being able to bind to the document of the iframe (and some do), it wouldn't work. The editor just hangs up and throws errors if you try the execute-before-open.

[Jared Jurkiewicz]

(In [21431]) Fixing issue with content setting and filter timing in dijit.Editor. \!strict fixes #10537

[Jared Jurkiewicz]

(In [21432]) Update button status after toolbar was started. \!strict refs #10537

[Jared Jurkiewicz]

(In [21433]) Adding automated test for prefilter execution properly occurs during initial content setting. \!strict refs #10537

[Jared Jurkiewicz]

(In [21693]) Fix minor issue with test of filters on IE8. refs #10537