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/> > _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/
