myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Rossi <jer...@hotmail.co.uk>
Subject RE: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
Date Wed, 13 Feb 2008 16:51:30 GMT
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?


> Date: Sat, 15 Dec 2007 18:02:25 +0100
> From: harald@elkfilm.de
> To: users@myfaces.apache.org
> Subject: Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
> 
> Ok, I tried the newest version of Tomcat (6.0.14) which reduced the 
> number of ClientAbortExceptions, although they still occur.
> The problem still persists that after closing a dialog, the link for 
> opening it up again is not clickable for about 10 seconds (meaning 
> nothing happens when you click on it).
> 
> Oh, and for Opera, dialogs won't work at all. After clicking on a link 
> that should launch a dialog, Opera seems to hang in a loop, reloading 
> the base page over and over again.
> 
> So, anyone here who can provide me with some help? A developer who can 
> tell me what changes have been made to the dialog framework between 
> 1.2.2 and 1.2.3?
> Also, should I file this as a bug?
> 
> Harald.
> 
> Harald Stangl schrieb:
> > Hello,
> >
> > we're developing a browser game using JSF 1.2_04 (Sun RI) and Trinidad.
> >
> > Until now we are using Trinidad 1.2.2 where the lightweight dialogs 
> > work fine for both Internet Explorer and Firefox.
> >
> > But when we switched to Trinidad 1.2.4, the lightweight dialogs no 
> > longer worked reliably in Firefox. When clicking on a link that should 
> > launch a dialog often nothing happens at all, and sometimes the 
> > following Exception is thrown:
> > ClientAbortException:  java.net.SocketException: Software caused 
> > connection abort: socket write error
> >
> > When trying to spot the error, I made a peculiar observation:
> > I included a Phase Listener for the RestoreViewPhase (although the 
> > phase is irrelevant in this case) that does nothing but gives me the 
> > possibility to set a break point. With Trinidad 1.2.2, the phase 
> > listener is called twice sequentially from the same thread upon the 
> > call of the dialog. I assume the first call is for the processing of 
> > the base page and the second one for the dialog page.
> >
> > But starting with Trinidad 1.2.3, the phase listener is called *four* 
> > times, where the two first calls occur sequentially as before, and the 
> > third and forth call happen in two different threads in parallel. This 
> > behaviour is special to Firefox; opening the dialog with Internet 
> > Explorer, only two sequential calls as with Trinidad 1.2.2 are being 
> > executed.
> >
> > I created a very simple test setup consisting of only two nearly empty 
> > pages (the base page and the dialog page), and a backing bean that 
> > handles the closing of the dialog when the "close" link in the dialog 
> > page is clicked. I also disabled any other filters or listeners to 
> > eliminate potential error sources. If there is any interest, I will be 
> > glad to post my demo files. Any help to solve this problem is 
> > appreciated.
> >
> > Thanks,
> > Harald.
> >
> 

_________________________________________________________________
Free games, great prizes - get gaming at Gamesbox. 
http://www.searchgamesbox.com
Mime
View raw message