Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9948 closed Bug (invalid)

BLUR and FOCUS events not correct

Reported by: Open eSignForms Owned by:
Priority: Normal Milestone:
Component: General Version: 4.0.1
Keywords: Cc:

Description

We see this problem mostly on Firefox, Chrome and Safari, but not IE or Opera.

It seems that various actions cause BLUR and FOCUS events to fire even though they don't seem like they ought to (the focus is still in the CKEditor instance).

We see these fire rapidaly on a PASTE operation.

We see these fire rapidly on a RIGHT-CLICK in a TABLE CELL (to bring up the table context menu).

Why are these actions within the editor considered to create BLUR and FOCUS events?

(As reported in the forum: http://ckeditor.com/forums/Support/BLUR-and-FOCUS-events-not-correct)

Change History (8)

comment:1 Changed 6 years ago by Jakub Ś

Status: newpending

This it not enough information.

  1. Which editor do you use 3.x or 4.x (I assume the second but please confirm)?
  2. Could you provide reduced sample showing the problem (I'm talking about same html page that can be put in samples folder and will show the problem)?

Sure that I could just attach blur and focus events to editor but instead of guessing what you had in mind I think you will agree that sample from you will save us both some time.

  1. Could you provide detailed steps that explain how to reproduce this problem?
  2. Can this be reproduced in plain and freh CKEditor without any customizations or this problem occur in your webapp or in customized editor?

Please reply to all questions.

comment:2 Changed 6 years ago by Open eSignForms

Yes, this happens under 4.0.1.

First, the blur event must be immediate (like forced blur previously) since the editor is included in a web 2.0 site that needs to retrieve and send the editor contents to the server when the user is leaves the editor area.

I won't reproduce in the standard demo editor because there is no blur/focus event handling. I suspect if you do an 'alert' or write to a log whenever the focus and blur events fire, you'll see this happen. We basically wait until the instance ready event fires, then we attach blue and focus event handlers.

By putting debug statements in our blur and focus handlers, we see them fire just from a PASTE operation or a right-click in a table to bring up the properties editor.

We are looking for a focus/blur to only occur when the editor itself gets and loses focus without regard to such operations that appear to be all "within" the editor.

comment:3 Changed 6 years ago by Jakub Ś

I assume this is continuation of #9948.

I have asked you for the sample because we are getting into area that I don't like. I write something that works but this is not what user is having and so on.

Please provide sample code that is causing this problem.

I have tries this code on my page.

var editor = CKEDITOR.replace( 'editor1' );
			editor.on('blur', function(evt){
				console.log(evt);			
				console.log(evt.sender.name);			
				console.log('blur');			
			});

blur events were only fired when I have left editor.

  1. Is this how you were attaching event or in some other way - you have modified core of CKEditor like it was described in #9949?
  2. Does the above work for you?

comment:4 Changed 6 years ago by Open eSignForms

Yes, I think you can only see these fire if you are using "force blur" (it was an API method in 3.x, but no longer seems to be the case in 4.x). So you can see if you do this:

CKEDITOR.focusManager.prototype.orig_blur = CKEDITOR.focusManager.prototype.blur;
CKEDITOR.focusManager.prototype.blur = function() { CKEDITOR.focusManager.prototype.orig_blur.call(this,true); };
    
var editor = CKEDITOR.replace('editor1');
editor.on('blur', function(evt){
                console.log(evt);
                console.log(evt.sender.name);
                console.log('blur');
});
editor.on('focus', function(evt){
            console.log(evt);
            console.log(evt.sender.name);
            console.log('focus');
});

Then, when you PASTE or right-click in a TABLE cell, you will see the fast blur/focus events are suppressed if allow for the 100msec (1/10th of a second) standard blur to be used.

The issue we experience with CKEditor embedded into the Vaadin/GWT framework is that various controls on the "web 2.0" UI can trigger the upload of data entered in a page. That is, there's no SAVE button in CKEditor, and CKEditor is often just one field among many others. So the solution under 3.x was to use the force blur so that when the user leaves the editor area and triggers the blur event, we can capture the contents of the editor so it's ready to be shipped via AJAX back to the server.

If we don't force the blur event, then it's possible for a user to leave the editor and click a button that causes the data to be sent to the server before the blur event function is called and we can prepare the editor data for transmission.

comment:5 Changed 6 years ago by Piotrek Koszuliński

Resolution: invalid
Status: pendingclosed

I'll reply here for both tickets - this and #9949.

  1. Focus manager was created to manage many focusable UI parts (editable area, dialogs, toolbar, context menus, dropdowns, etc) as a one focusable interface.
  2. In various cases focus is moved from one UI part to another asynchronously. Thus, there has to be a timeout before focus manager can tell that entire editor interface has been blurred. Note: this timeout equals 200ms (not 100ms - docs are wrong) and is stored in focusManger._.blurDelay.
  3. This delay is now set to safe value (but not unreasonable). You can try to decrease it, but you can't make this synchronous.
  4. focusManager#blur does not mean that editor has been blurred. Editor#blur event means this. focusManager#blur means that one part of editor's UI has been blurred.
  5. Sometimes it may happen that for brief moment editor contains some superfluous stuff. It happens especially often when some editor's UI part is blurred, because it means that focus is moved, so selection has to be remembered (spans wrapping selection), or pasted content handle (cke_pastebin). Currently editor.getData() may return some of these leftovers, but this situation will be significantly improved by CKE 4.1 (#9829).

Anyway, I don't understand the "web 2.0" UI issue. You would have to be very precise describing what happens. But anyway, this discussion should be moved to forum, because IMO it's a matter of solution, not a bug.

I'm closing this ticket. We can ofc reopen it if there really is an unsolvable issue.

Last edited 6 years ago by Piotrek Koszuliński (previous) (diff)

comment:6 Changed 6 years ago by Open eSignForms

Please see forum posting: http://ckeditor.com/comment/123908#comment-123908

This shows the issue with blur/focus not firing correctly, buffer mismatches, etc. using just CKEditor in HTML.

comment:7 Changed 6 years ago by Piotrek Koszuliński

I'll check this later and reply here or on forum.

comment:8 Changed 6 years ago by Piotrek Koszuliński

I've finally replied to your question: http://ckeditor.com/comment/124373#comment-124373

Nothing changed - focus manager works correctly.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy