We're using MyFaces 1.2.2 - I've tried 1.2.3 and there's no
difference. We're also using Tomahawk 1.1.5 and Facelets 1.1.13.
I've tried Tomahawk 1.1.6 and Facelets 1.1.14 and, again, no
difference.
thanks
Joe.
CC: [email protected]; [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [email protected]
Subject: Re: [TRINIDAD] Dialog Framework behaving strange since
Trinidad 1.2.3
Date: Wed, 21 May 2008 00:06:03 -0600
Sounds strangely like a server issue. What JSF version are you using?
On May 20, 2008, at 11:14 PM, Joe Rossi <[EMAIL PROTECTED]> wrote:
Unfortunately it is still a problem in 1.2.7. Any clues as to what's
happening or how to track down the problem?
many thanks
Joe
> Date: Tue, 20 May 2008 16:47:13 -0600
> From: [EMAIL PROTECTED]
> To: [email protected]
> CC: [EMAIL PROTECTED]
> Subject: Re: [TRINIDAD] Dialog Framework behaving strange since
Trinidad 1.2.3
>
> Joe, is this a problem in Trinidad 1.2.7?
>
> Scott
>
> Joe Rossi wrote:
> > Harald - I'm not sure whether you solved your problem, but I've
> > finally come back to check this out again. Here's what I've
found over
> > the last couple of days with my particular test case:
> >
> > Just as a reminder the scenario I have is an intermittent problem
> > after a lightweight dialog has been launched and closed *and*if
the
> > closure of the dialog results in a PPR refresh to a component on
the
> > underlying page. Some additional observations:
> >
> > - After the dialog returns I cannot click on any further command
links
> > for exactly 8 seconds
> > - The expected PPR refresh does not occur
> > - Using Firefox Tamper Data plugin I can see that there are
POSTs to
> > the server which do not complete. Tamper Data reports them as
> > remaining with status 'Pending'
> > - After debugging trinidad's javascript I notice that all the
above
> > problems occur because the function _pprStopBlocking() is not
being
> > called in the same way as in 1.2.2. In 1.2.2 PPR triggers an
ajax call
> > to the server, the ajax call completes fine, the javascript
function
> > TrXMLRequest.__onReadyStateChange reaches the ready state and at
that
> > point the ppr response is correctly consumed on the client and
> > _pprStopBlocking() is called. On 1.2.3 the javascript function
> > TrXMLRequest.__onReadyStateChange never reaches the ready state
and so
> > the downstream actions of consuming the ppr response and calling
> > _pprStopBlocking() are not correctly done.
> > - Note that in the error condition, _pprStopBlocking is eventually
> > called by a separate javascript thread which is kicked off as
part of
> > the initial ppr processing in _pprStartBlocking(). The timeout
value
> > on this thread is exactly 8 seconds which explains the first
symptom
> > described above.
> >
> > So, it appears that the underlying cause is the ppr request not
> > completing.
> >
> > I've diffed the 1.2.2 and 1.2.3 source code and there's nothing
which
> > looks like a directly obvious cause. Can anyone help, or at
least give
> > some pointers on how to work out why the ppr request is not
completing?
> >
> > thanks
> > Joe.
> >
> >
> >
> >
---
---------------------------------------------------------------------
> > Date: Mon, 18 Feb 2008 13:02:57 +0100
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > CC: [email protected]
> > Subject: Re: [TRINIDAD] Dialog Framework behaving strange since
> > Trinidad 1.2.3
> >
> > Hi Joe,
> >
> > unfortunately I didn't get any response from the list, although I
> > tried it two times.
> > I opened a bug report in jira but did not get any comment on that.
> > Maybe I find some time to do a diff between 1.2.2 and 1.2.3 to
> > find out what changes have been made that could cause this
behaviour.
> >
> > Joe Rossi schrieb:
> >
> > Harald (anyone) - did you work out what's happening here? I
> > think I'm hitting something similar.
> >
> > We've been successfully using 1.2.2 for a few months, but
> > wanted to move up to 1.2.5 in order to consume a couple of bug
> > fixes that we need. However, a number of our Selenium UI tests
> > failed because of clicks on command links not responding after
> > dialogs had been displayed.
> >
> > I've spent a bit of time trying to work out what's happening
> > (not very successfully). The only observations I have made are:
> >
> > - The problem is intermittent but it only seems to occur after
> > a lightweight dialog has been launched and closed *and*if the
> > closure of the dialog results in a PPR refresh to a component
> > on the underlying page
> > - With firebug I can observe a javascript error occurring when
> > the problem reproduces: _callChained is not defined
> > DebugCommon1_2_5.js line 8408. Also, firebug seems to indicate
> > that there is a POST to the server which has no response
> > (though admittedly I'm not sure whether this is correct or
> > relevant?)
> > - I have tested Firefox and IE - it only seems to reproduce in
> > Firefox
> > - I've tested 1.2.3 up to 1.2.5 and the problem reproduces in
> > all these versions (other issues are currently preventing
> > testing of 1.2.6). Hence, it does seem like something that was
> > introduced in 1.2.3.
> >
> > Any clues anyone?
> >
> >
> >
> >
---
---------------------------------------------------------------------
> > Messenger's gone Mobile! Get it now!
> > <http://clk.atdmt.com/UKM/go/msnnkmgl0010000001ukm/direct/01/>
>
Get fish-slapping on Messenger!
