Regression on WebKit: "inserthtml" command fails on the editor in 1.3 (works fine in 1.2.3)

[lipik]

Run the attached test file in FF, IE & Chrome - upon clicking the "Add text!" button, the text is inserted in the editor as expected on FF & IE7, but not in Chrome.

I do not have access to IE8, so it would be good if someone can verify the behaviour on that platform as well.

[lipik]

simple test case

[lipik]

update: it seems that the text is inserted in Chrome only after a key is typed, or Editor is clicked - i.e. editor changes state once it sees the first keystroke. Whatever is being toggled there, should also be set when text is inserted programmatically.

I also tried adding a call to focus the editor just before text is inserted - did not make a difference.

Even when the text is inserted (after clicking the editor), the trailing space is stripped only the first time (again, only in Chrome). This is inconsistent & unexpected (though minor).

[bill]

I'm not seeing a regression. It works in both cases but you need to focus the editor first. (I'm not sure why you need to do that; perhaps so there's a caret position defined? Or something about initializing the iframe?)

[lipik]

Surely you see the difference in behaviour? The add button works right out of the bat in FF & IE, but not in Chrome, unless the editor is clicked or a key is typed?

This did not happen with dijit 1.2.3 (see ​http://lipik.in/english.html for a live site using 1.2.3). This site does not work if I load dojo 1.3 instead of 1.2.3.

[bill]

I see a difference between FF and Chrome, but not between 1.2 and 1.3. Can you upload a test case that shows a regression?

[lipik]

Hi,

Sorry, I did not realize you had asked for more info. old file had a bug (dojoBlankHTMLUrl was not specified). I have attached another file that shows the regression - just change dojo version to 1.3, and you will see that the editor is not initialized correctly on Chrome (the console.log call in doInit() is not reached).

[lipik]

Hi,

I finally tracked this down, since it has become imperative for me to upgrade to 1.3+ now (needed new Opera + IE support).

The problem appears to arise because the following line was removed from RichText?.open() method in version 1.3:

if(html == ""){ html = " "; }

Apparently, the Webkit editor remains disabled until a keypress event if the edited document has no content.

I have added the following workaround to my code, which fixes the behaviour:

dojo.isWebKit && dojo.extend(dijit.Editor, {
	_getIframeDocTxt: function(html) {
		if (!html)
			html = " ";
		return this.inherited("_getIframeDocTxt", arguments);
	}
});

Leaving the defect open so the dijit Editor overlords can verify my hypothesis, and hopefully restore the previous behaviour.

[bill]

There's code for adding   in trunk, but it just runs for FF, not safari. We could take out the if().

Speaking of trunk, the "add text" button doesn't work on trunk in any browser . And there's a more serious problem that I can't focus the editor (by clicking it) on FF3.5/mac. It's working on FF3.5/win.

[bill]

Ignore my last paragraph above about "speaking of trunk". It's working for me now; not sure what happened before.

I'm not able to fix this error on trunk or on 1.3. I tried your workaround code above and other code changes too. As you said originally, the Editor doesn't seem to activate until you click it, and that's true even for an editor with original contents (like <div dojoType=dijit.Editor>Hello world</div>).

So, I'm not sure how to fix this problem, or if it's fixable. Might just be the way editable iframe's work. Maybe you can give the exact patch file that you used to fix 1.3 (or better yet, trunk)? Although, you should file a CLA first if it's more than a few lines.

[lipik]

Hi Bill,

Ta for following this up. I am attaching some code that has all the fixes I had to put in to get the editor to work OK on FF3.5, IE7 & Chrome v2.

The code will fail on Chrome (intentional) , but remove the "false && " on line 27, and it magically starts working. I suspect that the situation is complicated on WebKit? because rendering CSS images for the toolbar causes Editor to lose focus - I stumbled upon this because without the timeout on line 40, sometimes I see the cursor appear for a second and then disappear again.

[lipik]

Updated code to fix these problems

[lipik]

oops, "false && " on line 22

[bill]

Cool, thanks. Hmm I thought I tried this and it wasn't working for me, but your example works so I must have messed something up.

[bill]

(In [20102]) Limit cases where   is used to FF2 and webkit (where it's needed). It was causing failures in the EnterKeyHandling? regression suite for IE. Refs #9151 !strict.

[bill]

Fixed in [20100] and [20102].

[bill]

(In [20108]) Fix regression from [20100] where tabbing to second editor, selecting text via ctrl-a, then typing something doesn't erase selected text. Refs #9151, #9892 !strict.

[bill]

Note that this broke again in 1.9. However, ed.set("value", "hello") works fine, so I don't see a reason to fix it. I'll attach test files though for possible reference in the future, and check in an automated test.

[bill]

still working in 1.8

[bill]

broken in 1.9

[bill]

but working with official ed.set("value", ...) api

[Bill Keese <bill@…>]

In 66633d40e085c5a334164225ace5985afdb78603/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Bill Keese <bill@…>]

In 1ca2595bedceff33c45391a777268f672ffcf1b9/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled?