#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)
Change History (23)
Changed 11 years ago by
Attachment: | editor-test.html added |
---|
comment:1 Changed 11 years ago by
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 11 years ago by
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 11 years ago by
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 11 years ago by
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 11 years ago by
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 11 years ago by
Attachment: | editor-regression.html added |
---|
comment:6 Changed 10 years ago by
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
Milestone: | tbd → 1.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
Priority: | high → normal |
---|---|
severity: | major → normal |
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
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
Attachment: | editor-regression-v2.html added |
---|
Updated code to fix these problems
comment:11 Changed 10 years ago by
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
(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.
comment:13 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:14 Changed 10 years ago by
comment:15 Changed 6 years ago by
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
Attachment: | editor-test-1.9-working.html added |
---|
but working with official ed.set("value", ...) api
simple test case