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/>
