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