Opened 10 years ago

Closed 10 years ago

Last modified 6 years ago

#9151 closed defect (fixed)

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

Reported by: lipik Owned by: bill
Priority: high Milestone: 1.4
Component: Editor Version: 1.3.0
Keywords: editor, regression Cc:
Blocked By: Blocking:

Description

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.

Attachments (6)

editor-test.html (1.2 KB) - added by lipik 10 years ago.
simple test case
editor-regression.html (2.3 KB) - added by lipik 10 years ago.
editor-regression-v2.html (2.3 KB) - added by lipik 10 years ago.
Updated code to fix these problems
editor-test-1.8.html (1.2 KB) - added by bill 6 years ago.
still working in 1.8
editor-test-1.9.html (1.2 KB) - added by bill 6 years ago.
broken in 1.9
editor-test-1.9-working.html (1.2 KB) - added by bill 6 years ago.
but working with official ed.set("value", ...) api

Download all attachments as: .zip

Change History (23)

Changed 10 years ago by lipik

Attachment: editor-test.html added

simple test case

comment:1 Changed 10 years ago by 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).

comment:2 Changed 10 years ago by 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?)

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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?

comment:5 Changed 10 years ago by 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).

Changed 10 years ago by lipik

Attachment: editor-regression.html added

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by bill

Milestone: tbd1.4
Owner: changed from liucougar to 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.

comment:8 Changed 10 years ago by bill

Priority: highnormal
severity: majornormal

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.

comment:9 Changed 10 years ago by 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.

Changed 10 years ago by lipik

Attachment: editor-regression-v2.html added

Updated code to fix these problems

comment:10 Changed 10 years ago by lipik

oops, "false && " on line 22

comment:11 Changed 10 years ago by 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.

comment:12 Changed 10 years ago by bill

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

comment:13 Changed 10 years ago by bill

Resolution: fixed
Status: newclosed

Fixed in [20100] and [20102].

comment:14 Changed 10 years ago by 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.

comment:15 Changed 6 years ago by 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.

Changed 6 years ago by bill

Attachment: editor-test-1.8.html added

still working in 1.8

Changed 6 years ago by bill

Attachment: editor-test-1.9.html added

broken in 1.9

Changed 6 years ago by bill

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

comment:16 Changed 6 years ago by 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? 

comment:17 Changed 6 years ago by 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? 
Note: See TracTickets for help on using tickets.