IE: When editor gets the focus on load, the "del" key is not functional

[fassev@…]

Hi,

I found a reproducible problem with the versions 2.4 and 2.3.

Although the fckconfig.js contains...

FCKConfig.StartupFocus = false ;

... the fckeditor gets the focus after page is (re)loaded. In such case, the "Del"-key (character delete) is not functional until I click the mouse some ware in the text or change the focus to another control and then back to the fckeditor.

To reproduce this, please do the following:

1. Download the 2.4 Version, you don't have to change anything.
2. Start "default.html" (local file in the _sample directory) in the IE (6.1 or 7.0)
3. Click with the mouse some ware on the text within the editor, you must see the cursor now.
4. Click outside the editor (but in the same frame) with the right mouse key and select from the context menu "Refresh" (i.e. reload the frame)

The frame with the FCKeditor will be reloaded and the fckeditor will get the focus automatically after that - you will see the cursor within the editor. Try the "del"-key, which has no effect (you can not delete any character) until you click with the mouse within the editor or change the focus.

On some of my html pages I can reproduce this behavior after a page load (not only on reload), so there is a real focus problem within the new version.

Regards Peter

---

Moved from SF:
​http://sourceforge.net/tracker/index.php?func=detail&aid=1652033&group_id=75348&atid=543653

[fassev]

There is a really strange problem with the focus FCKEditor (Version 2.4) within IE (6.1 and 7.0) at page load. I have pages, where when the FCKEditor is loaded it gets visually the focus - I can directly write within it, whithout clicking with the mouse! -, but it actually does not hold the focus. The focus is hold by the next element, in this case it is a check box, later on the HTML page. When I type in the FCKEditor, the text is displayed, but when I type a space, the check box is switched on and off. Unbelievable, but it is true: It seams as 2 elements on one and the same page has the focus at the same time. This looks like a nice IE-Bug. I think this explanes the perviously described bug. Well, the FCKEditor is using a separate iframe, but nevertheless, this should not happen.

When I click the mouse into the editor or somewhere else in the page, the focus problem disappears. Verry annoying problem.

[Frederico Caldeira Knabben]

You said it well... it sounds like a very annoying IE bug.

Well... we need to investigate. If you could provide a test case page for it (with the checkbox magic), it would be handy.

Thanks for the update.

[fassev]

Well, you actually don't need any other page, you can use your own samples. Please do the following steps:

1) got into the "_semples\html" direktory, and open "sample01.html" into the IE 2) simply click 4 times (3 times for Version 2.3.2) the tab-Button (don't use the mouse!) 3) now you must see the focus within the editor together with the focus on the submit button. You can type a text, but as soon as you click the "space" button, you will see the page submitted!

As soon as you use your mouse (click somewhere on the page or within the editor) the problem with the double focus disappears.

Regards Peter

[Frederico Caldeira Knabben]

Ok... confirmed. I've tested it with versions 2.2 and 2.3.2 too with the same results. So it is not something introduced recently.

What a crazy thing, tough!

After 3 tabs, the editor "completely" got the focus and worked properly (with hatched borders around the editing area). After another tab, the focus went to the submit button, but the cursor was still blinking inside the editing are.

[shill@…]

Could this be related to a problem some of our users are seeing. When they try and delete text in IE they get a javascript error.

Line: 46 Char: 249 Error: Object required

This is in fckeditor.html

If the editor doesn't have focus then is could causes this problem ? Our solution at the moment is to switch to the source view and switch back and delete then works.

I've tried to replicate this problem but can't.

[Frederico Caldeira Knabben]

Replying to shill@extravision.com:

Could this be related to a problem some of our users are seeing. When they try and delete text in IE they get a javascript error.

I don't think it is related because the reported bug doesn't really throws errors. The del key simply has no effect in the text.

I've tried to replicate this problem but can't.

For you specific case, we would really need to reproduce it here in some way. If you find out how to do that, please open a specific ticket for it.

[fassev]

Helo Fred,

is there any progress with this problem? I would appreciate any help.

Thanks Peter

[Alfonso Martínez de Lizarrondo]

#417 has been marked as dup

[Jon Håvard Gundersen]

Hello!

A workaround is to call editorInstance.EditorWindow.focus(); after the editor is loaded, this seems to fix our problems with the keystrokes not beeing activated before mouseclick.

[Martin Kou]

Fixed with [481].

Click here for more info about our SVN system.

[Martin Kou]

Oops... sorry, the change set to the fix should be [482]. I read the wrong number from my ssh console.

[Frederico Caldeira Knabben]

Sorry fassev... you have reopened it, but do you have any comment on it?

[fassev]

sorry, my mistake, I had to ask "martinkou" first. But doesnt' he said, the fix was intended for 482? Or has this bug been fixed? I did't sow anything about the solution.

[Martin Kou]

Hi Peter,

The comments I wrote were pretty much canned responses. Sorry it might be hard to understand.

The bug was fixed in revision [482] in our SVN repository. Assuming you have the svn command on your system, you can check it out by the following command:

svn co http://svn.fckeditor.net/FCKeditor/trunk/@482

[Martin Kou]

If you see any more problems regarding this bug with the fixed version, just report it here and I'll fix it for you.

[Frederico Caldeira Knabben]

Replying to fassev:

sorry, my mistake, I had to ask "martinkou" first. But doesnt' he said, the fix was intended for 482? Or has this bug been fixed? I did't sow anything about the solution.

Pay attention to the brackets around [482]. It means the changeset [482], which introduced the code that fixed this ticket, not the ticket #482. It is just a matter of Trac's auto-linking syntax.

[Alfonso Martínez de Lizarrondo]

I'm experiencing now that loading the editor in IE makes the window blink for a moment: it disappears showing the window behind and then it shows again and it looks strange (it's less than a second, maybe 1/10 second).

It might be related also to this comment ​http://www.fckeditor.net/forums/viewtopic.php?f=6&t=6392#p17199

I've tried removing this patch and then everything seems to work fine, the editor doesn't get the focus now thanks to [569] (or so it looks to me), so we could remove this code if the problem is indeed solved by that patch and this one is problematic.

[Martin Kou]

Yes, [569] should have already fixed the problem, so [482] would be redundant.

I've uploaded the changeset [594] which removes the code added by [482]. Now both issues should be fixed.

[Jon Håvard Gundersen]

When setting FCKConfig.StartupFocus to true in Nightly build (ie7) I now get javascript error - crashes on line 9 in fckevents.js with code nr -2146827864 (no object).

If I disable StartupFocus and tries to manually set focus to the editorWindow with editorInstance.EditorWindow.focus() the focus is now set above the iframe and totally out of the editorarea :)

[Martin Kou]

I couldn't reproduce the JavaScript error on both IE6 and IE7. And line 9 of fckevents.js is the copyright notice. So I can't find out what IE has bumped into on your side.

I could reproduce the focus issue though. The fiddling with the unselectable attribute in [569] caused the focusing problem, so by fixing one focus bug we're getting another. I've changed the trick-fix from using the unselectable attribute to the disabled attribute, which works for both StartupFocus=true and StartupFocus=false on my computer.

I've committed the changes to [607]. Please take a look and see if you're still getting the JavaScript error or not.

[Jon Håvard Gundersen]

OK, now the focus is back, but then the old bug is back too..

I can not paste text with shortcut (ctrl-v) until I have clicked inside the editor with the mouse. Before I could use editorInstance.EditorWindow.focus() to fix that problem, but this does not work now. So it seems to be that even the cursor is inside the editor the focus is still outside somewhere.

StartupFocus is not causing any error so you fixed that (I don't know exactly what caused the error).

Another annoying bug is that the cursor seems to be set before the first element instead of inside it. Like this ^{<p>&nbsp;<p> instead of this <p>}&nbsp;</p>. Maybe this has a something to do with the focus not beeing set correctly in the first place.

[Jon Håvard Gundersen]

ops, the last sentence become wikified...

it should show you that the cursor were place like: |<p>&nbsp;<p> instead of expected: <p>|&nbsp;</p>

[Jon Håvard Gundersen]

When I remove everything but oDoc.body.contentEditable = true ; inside the actual area of the fckeditingarea.js file thing seems to work. The keystrokes work and startupfocus is working. And they didn't work in 2.4.3, so something has improved.

The cursor is still placed before the first element though, but this is maybe another bug?

[Martin Kou]

Ok, I added yet another kludge in [608] for the cursor position problem. I really wish the fix could be simpler, but this is the simplest I could come up with after more than an hour of trial and error.

Please take a look and see if there are any more problems.

[Jon Håvard Gundersen]

Very good! This seems to be the solution for the problems I have encountered. It should be possible to make a function at least to reduce the kludging... :)

[Martin Kou]

Ok, finally it's working. Closing the ticket.

[Frederico Caldeira Knabben]

I've done a small change to [608] with [623], including jonhg's suggestion to move the kludge to a function.