RichTextArea Instantiation Causes Comet Servlet Communication Failure on FireFox

[jsegal]

I've recently a control in the app I'm working on from a standard
TextArea to a RichTextArea. The new control works correctly on
Internet Explorer. If it is instantiated in FireFox (3.0.7), however,
I immediately get a Comet exception on the client side (Unable to
connect to "<Comet servlet URL>"), which causes the Comet
communication cycles to cease. I've tried eliminating all calls on the
RichTextArea control, and determined that instantiation alone seems to
cause the problem.

Can anyone explain why this is happening, or offer suggestions for
ways it might be fixed?

[mP]

This seems very strange as a RTA should not have any affect at all on
the hidden iframe used by the comet session.

Have you tried creating the RTA before starting your comet session ?

[jasons]

Good thought. I just tested this and found that a RichTextArea
instantiated before the Comet session starts will not cause problems.
Moving the instantiation after the session begins will disrupt the
session as I described. This makes me suspect that FireFox's
implementation of RichTextArea is somehow interacting with the hidden
IFRAME.

Unfortunately, creating the RichTextAreas I need before beginning the
Comet session is not an option in this app. I have to create new ones
dynamically in response the user's actions.

Do you have any idea how I might work around this?

[Miroslav Pokorny]

Have you tried running your app with rta after comet with firebug on ?
What does firebug tell you ? Are there any network or js errors ?

Hth

[jasons]

Firebug reports no JavaScript errors. It also isn't marking any of the
entries under its NET section as bad (I'm guessing this is where I'd
see network errors), but I'm not entirely sure what I should be
looking for there. I don't see any communication errors in the server
log, so I'm guessing this is just happening on the client.

I also used its HTML inspection feature to look at the IFRAME elements
for both the Comet session and the RichTextArea. I can't see any
obvious changes in the Comet IFRAME - the only thing that's different
after the RichTextArea is created is the number parameter at the end
of the SRC attribute (which is supposed to change regularly, if I
understand its purpose).

Is there anything else I should look at? Also can you (or anyone else)
reproduce this problem?

On Mar 20, 5:24 pm, Miroslav Pokorny <miroslav.poko...@gmail.com>
wrote:

> Have you tried running your app with rta after comet with firebug on ?  
> What does firebug tell you ? Are there any network or js errors ?
>
> Hth
>

[Miroslav Pokorny]

Can you try creating a simple roc back to the server when the comet
fails... Could it that somehow the new rta occupies the last possible
connection back to the server - I believe a browser is allowed at most
two cons back home...

???

[jasons]

ROC? Do you mean RPC?

I am able to communicate with the server using a normal GWT RPC
servlet after this happens, if that's what you're asking. In this app,
I'm sending data to the server using a normal GWT servlet, and getting
updates via Comet. I know that sending to the server continues to work
after this error (I'm debugging the server, so I can see messages
coming in), but Comet communication breaks down, so I'm not getting
new information from it.

If that isn't what you wanted me to try, please clarify your request.

Using up the maximum number of allowed connections does make some
sense - that's certainly one way cause such a failure - but I don't
see how it could be happening in this case. As far as I know, the
RichTextArea doesn't establish any kind of communication with the
server - it's just a control on the client. If I understand how it's
implemented properly, the control does use an IFRAME, but I don't
think it uses the SRC attribute of the IFRAME to do any kind of
communication. Also, if the RichTextAreas were somehow using up the
connections to the server, I expect it wouldn't matter whether I made
the control before or after establishing the Comet connection - the
connections would presumably still be allocated.

On Mar 20, 8:46 pm, Miroslav Pokorny <miroslav.poko...@gmail.com>
wrote:

> Can you try creating a simple roc back to the server when the comet  
> fails... Could it that somehow the new rta occupies the last possible  
> connection back to the server - I believe a browser is allowed at most  
> two cons back home...
>
> ???
>

[jasons]

Here are two more things I've discovered that may be useful.

First, I was wrong about instantiation causing the failure. The error
occurs only after the RichTextArea instance is added to the DOM.

Second, I've found a possible way around the problem. It looks like
I'm able to restart the dropped connection after a RichTextArea
appears. If the connection was successfully established (that is, if
it has received anything succussfullyso far), the onFailure method of
my CometCallback will now call CometClient.start(). This seems to get
communication cycles running again, although I'm concerned that this
technique might allow messages to be lost (I'm not yet sure whether
the error interrupts a pending Comet request, or stops the next one
from being made).

Even if it can be made safe, this work-around doesn't seem like a
great solution. If you have any other suggestions, please let me know.