Closed GoogleCodeExporter closed 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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
ryan130...@gmail.com
on 9 Feb 2013 at 4:02Attachments: