myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott O'Bryan <darkar...@gmail.com>
Subject Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
Date Wed, 21 May 2008 06:06:03 GMT
Sounds strangely like a server issue.  What JSF version are you using?

On May 20, 2008, at 11:14 PM, Joe Rossi <jeross@hotmail.co.uk> 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: darkarena@gmail.com
> > To: users@myfaces.apache.org
> > CC: harald@elkfilm.de
> > 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: harald@elkfilm.de
> > > To: jeross@hotmail.co.uk
> > > CC: users@myfaces.apache.org
> > > 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/>
> >
>

Mime
View raw message