UIDL posts when CKEditor widget in a Form only

I am mostly looking for advice on how to troubleshoot this problem. It has something to do with a Form, I think, but I’m not really positive yet.

I am using the CKEditor widget. In the sample app (demo at http://open.esignforms.com/VaadinCKEditor/), the editors are added directly to the MainWindow. I cannot reproduce the bug at all in this simple environment, and the demo shows it working just fine.

The bug shows itself under one specific scenario, and it’s not a bug with CKEditor as far as I can tell:

  1. Open the Form that shows the editor with the original contents.
  2. Hit ENTER in the editor window somewhere in the middle (this just makes it easier to note the bug as the location doesn’t really matter) to open up a line.
  3. Click on the INSERT TABLE button of CKEditor. A CKEditor popup window opens, but you can visibly see the text in the editor scroll in the Vaadin Form. When you complete the INSERT TABLE, it may be at the TOP or BOTTOM of the editor area, not where the cursor was positioned.

If you do not do step #2 (hit ENTER), and just position the cursor in the editor, it works fine.

Furthermore, once you experience this bug in an editing session, it cannot be reproduced. That is, you can do steps 2 & 3 repeatedly without ever seeing the scrolling bug. It’s only on the FIRST time you do it, and only IF you press ENTER (well, there may be other ways, but that’s the bug we’re tracking down now) before you insert the table.

It happens on all browsers, so it’s not just a browser bug. And of course, the demo version of this very editor widget does not show it, even with the ENTER step.

When I run Firebug, this is what I see.

a) Open the Form that shows the editor with the original contents.
b) Position the cursor in the middle somewhere, but do not press ENTER. Click INSERT TABLE and insert it.

This scenario works as expected and I see no network traffic in Firebug. B U T . . .

A) Open the Form that shows the editor with the original contents.
B ) Position the cursor in the middle somewhere. Hit ENTER. Click INSERT TABLE (but don’t actually even insert it yet)

This UIDL message is sent, presumably showing the changed editor buffer because I clicked ENTER, which inserted a new

section:


d7cddd97-d429-4419-be9b-89a12fba19571PID7clickedKeys2,93,63,false,false,false,false,8,-1,-1PID7clickEvents

PID125texts

At this point, you can see the editor contents visible scroll.

C) Click to complete the INSERT table, and new UIDL is sent, this time presumably because the table is now present, albeit at the bottom, not where it was supposed to go.


d7cddd97-d429-4419-be9b-89a12fba1957

PID125texts

But at this point, the bug of scrolling cannot be reproduced again. That is, I can go anywhere in the editor area, click ENTER to open a line and INSERT TABLE and the table goes to the right spot without any visible scrolling. In most of my tests, I don’t even see the clickedKeys/clickEvents in the UIDL, just the updated text, so that’s not part of the bug.

Any idea? Is there anything I can trace to help someone debug this with me? It is odd to have everything working nearly all of the time, but only on the first INSERT TABLE IF AND ONLY IF I press ENTER first. I believe that somehow CKEditor and Vaadin are competing at this step, but it’s odd that they only compete at this point and never again.

First time, when things break because of the scroll:

678041e8-2849-480c-8783-16f60964b6e2

Welcome to logo.

On the left side are the features you are authorized to access.

 

To secure your account, please click the Logoff button when you are done.

PID83texts

for(;;);[{“changes”:[[“change”,{“format”: “uidl”,“pid”: “PID13”},[“4”,{“id”: “PID13”,“style”: “padLeft5p”},“18:26:54 PDT”]
],[“change”,{“format”: “uidl”,“pid”: “PID81”},[“12”,{“id”: “PID81”,“width”: “100.0%”,“style”: “TipsForm”,“immediate”:true,“caption”: “Update the Welcome Message”,“icon”: “theme://icons/esf/fatcow16_information_edit.png”,“modified”:true},[“1”,{“id”: “PID82”,“cached”:true}]
,[“2”,{“id”: “PID84”,“cached”:true}]
]],[“change”,{“format”: “uidl”,“pid”: “PID83”},[“13”,{“id”: “PID83”,“height”: “410px”,“width”: “100.0%”,“immediate”:true,“modified”:true,“readonly”:false,“v”:{“text”:“

Welcome to <img alt="logo" src="http://open.esignforms.com/images/OpenESignFormsLogo.gif" style="width: 183px; height: 49px; vertical-align: -10px;" />.</h1>\n

On the left side are the features you are authorized to access.</p>\n

 </p>\n

To secure your account, please click the Logoff button when you are done.</i></p>\n”}}]
]], “meta” : {}, “resources” : {}, “locales”:}]

Next time when works fine:

678041e8-2849-480c-8783-16f60964b6e2

Welcome to logo.

On the left side are the features you are authorized to access.

 

 

To secure your account, please click the Logoff button when you are done.

   
   
   

 

PID83texts

for(;;);[{“changes”:[[“change”,{“format”: “uidl”,“pid”: “PID13”},[“4”,{“id”: “PID13”,“style”: “padLeft5p”},“18:28:23 PDT”]
],[“change”,{“format”: “uidl”,“pid”: “PID81”},[“12”,{“id”: “PID81”,“width”: “100.0%”,“style”: “TipsForm”,“immediate”:true,“caption”: “Update the Welcome Message”,“icon”: “theme://icons/esf/fatcow16_information_edit.png”,“modified”:true},[“1”,{“id”: “PID82”,“cached”:true}]
,[“2”,{“id”: “PID84”,“cached”:true}]
]]], “meta” : {}, “resources” : {}, “locales”:}]

and…

678041e8-2849-480c-8783-16f60964b6e2

Welcome to logo.

On the left side are the features you are authorized to access.

   
   
   

 

To secure your account, please click the Logoff button when you are done.

   
   
   

 

PID83texts

for(;;);[{“changes”:[[“change”,{“format”: “uidl”,“pid”: “PID13”},[“4”,{“id”: “PID13”,“style”: “padLeft5p”},“18:28:29 PDT”]
],[“change”,{“format”: “uidl”,“pid”: “PID81”},[“12”,{“id”: “PID81”,“width”: “100.0%”,“style”: “TipsForm”,“immediate”:true,“caption”: “Update the Welcome Message”,“icon”: “theme://icons/esf/fatcow16_information_edit.png”,“modified”:true},[“1”,{“id”: “PID82”,“cached”:true}]
,[“2”,{“id”: “PID84”,“cached”:true}]
]]], “meta” : {}, “resources” : {}, “locales”:}]

I don’t think sending the CONFIG info is the problem. I tried sending it only once, but then if I refresh the browser, it doesn’t have my config sent in the paintContent(). But there is something about this first interaction that causes the editor to scroll…but what is it!!!

Okay, while looking at the UIDL, which I really don’t understand, I noted that the Form is immediate, and that is different than when I add the editor directly to the MainWindow.

The editor field itself was always set immediate OFF, but I’m not sure what it means when a Form is immediate (so validators can run) but the editor field itself is NOT immediate (I don’t need anything from the editor until the user clicks on a button).

So, on one particular Form where I had this bug, I turned off immediate on the Form as it actually has no validators in the form. The bug is no longer a problem.

So, it’s related to the immediate on the Form, yet only seems to cause the scroll bug the very first time. When I continue to work in the editor, the bug never occurs again.

Perhaps now someone can help me since this is more Vaadin-related than the earlier confusion I was having? :slight_smile:

I can’t always turn immediate off since sometimes the editor is in a field that actually has validators for other fields. Is there anything I can do with my editor widget to perhaps avoid this “first time update” issue causing the editor to lost its cursor focus (and visibly scroll)?


A bit more testing shows that even turning off with Form.setImmediate(false) isn’t enough, though it’s less of a user concern since the insert table or the like doesn’t get messed up.

What happens, though, is I can click ENTER, INSERT TABLE, all is good, but if then click on a button elsewhere on my Form – just the first time still – the editor area scrolls again. But since my cursor is not in the editor, there’s no “error” other than the fact that the position is lost. I guess this is because even without immediate, when I click on a button, it transmits the changes that cause the editor to scroll. But only on the first time.

What would the first time do this but subsequent changes and button clicks and the like never cause the editor to scroll?

Anyone have an idea on how I can best troubleshoot this? I seems that somehow this first operation with Vaadin causes a refresh that doesn’t happen afterwards. Since it occurs on all browsers, does not happen outside a Form, it seems to be related to Vaadin, though it could be my code somewhere, too.

Thanks for any tips or ideas to investigate… David

Is there a way to create a Form with some sort of deferred command that can cause a “fake button press” to do the “first operation” sync when the Form is first created? There must be a way to keep the first button press on a Form from causing a redrawing that causes the scrolling bug I see.

This bug is not just related to CKEditor. I noted that a Form containing a TextArea suffers the same problem.

  1. Create a Form with a TextArea, showing perhaps 5 lines. Include another widget like a NativeSelect and ensure the Form or NativeSelect is in immediate mode.
  2. Enter 1, 2, 3, 4…10 so each is on its own line, ensuring that the TextArea is full and has scrolled.
  3. Click on the drop down icon of the NativeSelect.

Note that the TextArea scrolls to the top. Is this bug already known? I am not getting any response to it, so don’t know if more info is needed, how to debug it best, or how to resolve it. Any ideas are welcomed!

Here’s a SWF showing this behavior
11714.swf (267 KB)

Here’s a youtube showing this bug:


http://www.youtube.com/watch?v=3ta1_5TeL9c

Created ticket on this:
http://dev.vaadin.com/ticket/7121

Hi, sorry for digging this old post, but currently I am facing a problem. I am using ck as a field for my form, which has a custom FormFieldFactory, and I override the attachField method. My form is in a subwindow. If this form is in the mainwindow, everything works just fine. But attach form to the subwindow make an internal error, and here is the error:
Sep 28, 2011 5:02:18 PM com.vaadin.Application terminalError
SEVERE: Terminal error:
java.lang.NullPointerException
at org.vaadin.openesignforms.ckeditor.CKEditorTextField.paintContent(CKEditorTextField.java:71)
at com.vaadin.ui.AbstractComponent.paint(AbstractComponent.java:755)
at com.vaadin.ui.AbstractOrderedLayout.paintContent(AbstractOrderedLayout.java:171)
at com.vaadin.ui.AbstractComponent.paint(AbstractComponent.java:755)
at com.vaadin.ui.Form.paintContent(Form.java:207)
at com.vaadin.ui.AbstractComponent.paint(AbstractComponent.java:755)
at com.vaadin.ui.AbstractOrderedLayout.paintContent(AbstractOrderedLayout.java:
Did you face this problem? If yes please reply me how you solved it.
Thanks a lot,
Dan Le

Ok, I got the problem. It’s because the value of the field in my beanitem is null. I think you’re the developer of CK wrapper for Vaadin, right? So can you please add the check for null in the paintContent function, so if they set value to null, the editor still valid and rendered?
Thanks

Can I suggest new topics like this be posted as a new message? It doesn’t help anybody who is trying to work a given topic to see an entirely new topic be introduced in the middle. This is not related to the UIDL issue in a Form that causes text to scroll (both for CKEditor and for the Vaadin TextArea).

Yeah, sorry. Nice day! :smiley: