OpenESignForms / vaadin-ckeditor

Vaadin component wrapper around CKEditor
4 stars 11 forks source link

Blur event often occurs after mouse click event on another element #26

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Enter data in editor
2. Click a button to submit
3. In reading the data server side it is the old value

What is the expected output? What do you see instead?
I expect to see the data that is in the editor, not the old data.

What version of the product are you using? On what operating system?
Reproducible in the demo application. Tested on 2 machines using chrome and 
firefox.

Please provide any additional information below.

Doesn't happen all the time. Appears to happen more often if you drag over the 
existing text, type new text and then hit the button. Then drag over text, type 
new text, hit the button, etc. It appears the blur event is fired AFTER the 
click event from the button. Happens much more often in my local application. 
So much so that I made the button click add a refresher which when that is 
fired reads the value. It allows time for the blur event to happen.

Also I have tried using the editor in a popup window, but on clicking outside 
the popup to close it, the blur event is never fired. On opening the popup 
again the editor has returned to it's initial data.

Original issue reported on code.google.com by ryan130...@gmail.com on 9 Feb 2013 at 4:02

Attachments:

GoogleCodeExporter commented 9 years ago
Yes, this is a long-standing problem since moving to CKEditor 4.  In CKEditor 
3, we were able to use the forceBlur feature, but that was removed in CKEditor 
4.  We are using a scheme suggested by CKEditor folks to shorten the "blur 
delay" from 200msecs (the default in CKEditor), but it does seem brittle.

When I tried, I cannot make it happen, but I do know this occurs from time to 
time, the result of that timing.  I think we're using 70msecs now, but I can 
try a build with the delay reduced even further, but hope that it doesn't then 
sometimes submit an interim buffer that can be even trickier to deal with.

We are looking for a good solution to this issue, but are not sure what it is.  
We may just trying reducing the blur delay further, but what we've found is 
that you can then end up with an intermediate editor buffer contents, which can 
be even stranger because it may include constructs for text replacement and 
even a temporary body tag that can make the entire editor contents seem to 
disappear (because it becomes essentially an invalid DOM) until you click 
"save" again so that you get the final buffer.

The issue seems to be that there's no good way to know when to read the editor 
contents. We were using the BLUR event, but that only fires when you click 
outside the editor, and if that click is a Vaadin button, the BLUR event 
sometimes has not yet fired (it's really bad when using the CKEditor default 
value of 200msecs and requires two Vaadin button clicks to get it right!).  But 
we're reading the contents to send back to the server on the BLUR event.  

If you use the "Vaadin Save Button" plugin to the editor, this is never a 
problem because the editor and button are part of the same widget, so when that 
button is pressed, the latest fully updated editor contents are sent to the 
server.  The issue is when using a Vaadin button that is not otherwise related 
to the editor.

Another workaround for now is to use version 1.6.7 which was the last based on 
CKEditor 3.

What would be nice would be a hook so that whenever any Vaadin component is 
going to send data back to the server (like a button click), we could then tie 
in and read the editor contents.  This would be something like a 
form.onsubmit() capability that would be present in a more traditional web+JS 
scenario.

For ideas, please let us know or comment on the CKEditor forums. Some topics we 
created on this:
http://ckeditor.com/forums/CKEditor/CKEditor.editable.blur-or-other-scheme-to-de
tect-user-left-the-editor
http://ckeditor.com/forums/Support/BLUR-and-FOCUS-events-not-correct
http://ckeditor.com/forums/Support/span-displaynone-and-body-idckepastebin-appea
ring-in-buffer
http://ckeditor.com/forums/Support/How-to-force-blur-for-all-blur-events-in-CKEd
itor-4.0

Original comment by yoz...@gmail.com on 9 Feb 2013 at 7:08

GoogleCodeExporter commented 9 years ago
Can you try again on the demo system: 
https://open.esignforms.com/VaadinCKEditor/

We have reduced the blur delay from the default of 200msecs to 70msecs in the 
1.7.4 release, and now we've dropped it to 50msecs. This causes some small 
issue with Safari browsers doing right-clicks to bring up CKEditor 
context-menus if the vaadin editor widget has blur/focus event listeners 
enabled (but even this can be done by right-clicking again if the popup doesn't 
stick). That seems the lesser of two evils so if this works for you, we can 
release the changes.

Original comment by yoz...@gmail.com on 9 Feb 2013 at 8:08

GoogleCodeExporter commented 9 years ago
Thanks for the explanation and the quick feedback. It still does it for me in 
the demo application. It might not be doing it as much, it is hard to tell. I 
have a very fast computer, I'm not sure if that makes a difference. I'll give 
the version 1.6.7 a go and see how it goes.

It sounds like the issue is quite fundamental to CKEditor version 4. So 
hopefully it gets worked out! It's fantastic apart from that issue.

Original comment by ryan130...@gmail.com on 10 Feb 2013 at 1:24

GoogleCodeExporter commented 9 years ago
That's too bad.  I don't know if a faster computer makes a difference or not.  
I could not even reproduce what you are seeing when the delay was 70 as before, 
so at 50, it seemed fine too.  Just for grins, I've created one now just set at 
20.  If you can tell me if the demo system still shows the problem I'd be 
interested since it all seems fine here.  What I don't know is if CKEditor 
itself is enforcing any minimum values for the blur delay.

Original comment by yoz...@gmail.com on 10 Feb 2013 at 3:17

GoogleCodeExporter commented 9 years ago
I just gave it a test and I couldn't get it to do it this time. So maybe 20ms 
is good :). If you do decide to release it, I'll give it a test locally. In my 
local vaadin project the issue would happen nearly every time. CKEditor v3 
works no worries, but it doesn't look anywhere near as nice :)

Original comment by ryan130...@gmail.com on 10 Feb 2013 at 5:18

GoogleCodeExporter commented 9 years ago
Okay, that's great. Let me just test the 20ms version against the Safari 
browser with blur/focus event listeners and see how it performs, but if it's 
not totally unusable, we'll release it tomorrow.

Original comment by yoz...@gmail.com on 10 Feb 2013 at 5:30

GoogleCodeExporter commented 9 years ago
Fixed in 1.7.5 by reducing the blur delay to 20. Thanks Ryan for testing it 
out.  This creates another known issue for Safari browsers if the widget 
registers focus/blur event handlers, mostly with right-click context menus.  
For now, we think that's a lesser issue than sometimes not getting the editor 
updates.

Original comment by yoz...@gmail.com on 10 Feb 2013 at 5:52

GoogleCodeExporter commented 9 years ago
Thanks. Can confirm it is also working in my local project now.

Original comment by ryan130...@gmail.com on 10 Feb 2013 at 8:11