Opened 17 years ago

Closed 17 years ago

Last modified 15 years ago

#141 closed Bug (fixed)

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

Reported by: fassev@… Owned by:
Priority: Normal Milestone: FCKeditor 2.5 Beta
Component: General Version: FCKeditor 2.4
Keywords: SF IE Confirmed Cc:

Description

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

Change History (31)

comment:1 Changed 17 years ago by Frederico Caldeira Knabben

Reporter: changed from Frederico Caldeira Knabben to fassev@…

comment:2 Changed 17 years ago by 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.

comment:3 Changed 17 years ago by Frederico Caldeira Knabben

Keywords: IE added

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.

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

comment:5 Changed 17 years ago by Frederico Caldeira Knabben

Keywords: Confirmed added

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.

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

comment:7 in reply to:  6 Changed 17 years ago by 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.

comment:8 Changed 17 years ago by fassev

Helo Fred,

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

Thanks Peter

comment:9 Changed 17 years ago by Alfonso Martínez de Lizarrondo

#417 has been marked as dup

comment:10 Changed 17 years ago by Frederico Caldeira Knabben

Milestone: FCKeditor 2.5

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

comment:12 Changed 17 years ago by Martin Kou

Fixed with [481].

Click here for more info about our SVN system.

comment:13 Changed 17 years ago by Martin Kou

Resolution: fixed
Status: newclosed

comment:14 Changed 17 years ago by Martin Kou

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

comment:15 Changed 17 years ago by fassev

Resolution: fixed
Status: closedreopened

comment:16 Changed 17 years ago by Frederico Caldeira Knabben

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

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

comment:18 Changed 17 years ago by 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

comment:19 Changed 17 years ago by 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.

comment:20 in reply to:  17 Changed 17 years ago by Frederico Caldeira Knabben

Resolution: fixed
Status: reopenedclosed

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.

comment:21 Changed 17 years ago by Alfonso Martínez de Lizarrondo

Resolution: fixed
Status: closedreopened

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.

comment:22 Changed 17 years ago by Martin Kou

Resolution: fixed
Status: reopenedclosed

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.

comment:23 Changed 17 years ago by Jon Håvard Gundersen

Resolution: fixed
Status: closedreopened

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 :)

comment:24 Changed 17 years ago by 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.

comment:25 Changed 17 years ago by 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.

comment:26 Changed 17 years ago by 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>

comment:27 Changed 17 years ago by 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?

comment:28 Changed 17 years ago by 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.

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

comment:30 Changed 17 years ago by Martin Kou

Resolution: fixed
Status: reopenedclosed

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

comment:31 Changed 17 years ago by Frederico Caldeira Knabben

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

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy