Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 60501 invoked from network); 13 Feb 2008 16:52:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Feb 2008 16:52:10 -0000 Received: (qmail 29032 invoked by uid 500); 13 Feb 2008 16:52:00 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 28979 invoked by uid 500); 13 Feb 2008 16:51:59 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 28967 invoked by uid 99); 13 Feb 2008 16:51:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2008 08:51:59 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jeross@hotmail.co.uk designates 65.55.175.166 as permitted sender) Received: from [65.55.175.166] (HELO blu139-omc1-s26.blu139.hotmail.com) (65.55.175.166) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2008 16:51:10 +0000 Received: from BLU119-W17 ([65.55.162.183]) by blu139-omc1-s26.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Feb 2008 08:51:31 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_7c39940d-de8c-4f25-9e68-1f67e3d65050_" X-Originating-IP: [193.32.3.83] From: Joe Rossi To: MyFaces Discussion , Subject: RE: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3 Date: Wed, 13 Feb 2008 16:51:30 +0000 Importance: Normal In-Reply-To: <476408A1.4080806@elkfilm.de> References: <4762A374.1070408@beople.de> <476408A1.4080806@elkfilm.de> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2008 16:51:31.0118 (UTC) FILETIME=[AEF3ACE0:01C86E60] X-Virus-Checked: Checked by ClamAV on apache.org --_7c39940d-de8c-4f25-9e68-1f67e3d65050_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald (anyone) - did you work out what's happening here? I think I'm hitti= ng 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 succ= essfully). The only observations I have made are: - The problem is intermittent but it only seems to occur after a lightweigh= t dialog has been launched and closed *and*if the closure of the dialog res= ults 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 releva= nt?) - I have tested Firefox and IE - it only seems to reproduce in Firefox =0A= =0A= - I've tested 1.2.3 up to 1.2.5 and the problem reproduces in all these ver= sions (other issues are currently preventing testing of 1.2.6). Hence, it d= oes 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 >=20 > Ok, I tried the newest version of Tomcat (6.0.14) which reduced the=20 > number of ClientAbortExceptions, although they still occur. > The problem still persists that after closing a dialog, the link for=20 > opening it up again is not clickable for about 10 seconds (meaning=20 > nothing happens when you click on it). >=20 > Oh, and for Opera, dialogs won't work at all. After clicking on a link=20 > that should launch a dialog, Opera seems to hang in a loop, reloading=20 > the base page over and over again. >=20 > So, anyone here who can provide me with some help? A developer who can=20 > tell me what changes have been made to the dialog framework between=20 > 1.2.2 and 1.2.3? > Also, should I file this as a bug? >=20 > Harald. >=20 > 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=20 > > work fine for both Internet Explorer and Firefox. > > > > But when we switched to Trinidad 1.2.4, the lightweight dialogs no=20 > > longer worked reliably in Firefox. When clicking on a link that should= =20 > > launch a dialog often nothing happens at all, and sometimes the=20 > > following Exception is thrown: > > ClientAbortException: java.net.SocketException: Software caused=20 > > 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=20 > > phase is irrelevant in this case) that does nothing but gives me the=20 > > possibility to set a break point. With Trinidad 1.2.2, the phase=20 > > listener is called twice sequentially from the same thread upon the=20 > > call of the dialog. I assume the first call is for the processing of=20 > > the base page and the second one for the dialog page. > > > > But starting with Trinidad 1.2.3, the phase listener is called *four*=20 > > times, where the two first calls occur sequentially as before, and the= =20 > > third and forth call happen in two different threads in parallel. This= =20 > > behaviour is special to Firefox; opening the dialog with Internet=20 > > Explorer, only two sequential calls as with Trinidad 1.2.2 are being=20 > > executed. > > > > I created a very simple test setup consisting of only two nearly empty= =20 > > pages (the base page and the dialog page), and a backing bean that=20 > > handles the closing of the dialog when the "close" link in the dialog=20 > > page is clicked. I also disabled any other filters or listeners to=20 > > eliminate potential error sources. If there is any interest, I will be= =20 > > glad to post my demo files. Any help to solve this problem is=20 > > appreciated. > > > > Thanks, > > Harald. > > >=20 _________________________________________________________________ Free games, great prizes - get gaming at Gamesbox.=20 http://www.searchgamesbox.com= --_7c39940d-de8c-4f25-9e68-1f67e3d65050_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald (anyone) = - did you work out what's happening here? I think I'm hitting something sim= ilar.

We've been successfully using 1.2.2 for a few months, but want= ed to move up to 1.2.5 in order to consume a couple of bug fixes that we ne= ed. 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 successfu= lly). The only observations I have made are:

- The problem is interm= ittent but it only seems to occur after a lightweight dialog has been launc= hed and closed *and*if the closure of the dialog results in a PPR refresh t= o a component on the underlying page
- With firebug I can observe a java= script error occurring when the problem reproduces: _callChained is not def= ined DebugCommon1_2_5.js line 8408. Also, firebug seems to indicate that th= ere is a POST to the server which has no response (though admittedly I'm no= t sure whether this is correct or relevant?)
- I have tested Firefox and= IE - it only seems to reproduce in Firefox
=0A= =0A= - I've tested 1.2.3 up to 1.2.5 and the problem reproduces in all these ver= sions (other issues are currently preventing testing of 1.2.6). Hence, it d= oes seem like something that was introduced in 1.2.3.

Any clue= s anyone?


> Date: Sat, 15 Dec 2007 18= :02:25 +0100
> From: harald@elkfilm.de
> To: users@myfaces.apac= he.org
> Subject: Re: [TRINIDAD] Dialog Framework behaving strange si= nce Trinidad 1.2.3
>
> Ok, I tried the newest version of Tomca= t (6.0.14) which reduced the
> number of ClientAbortExceptions, alth= ough they still occur.
> The problem still persists that after closin= g 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 clickin= g 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:
> > Hel= lo,
> >
> > 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 b= oth Internet Explorer and Firefox.
> >
> > But when we sw= itched to Trinidad 1.2.4, the lightweight dialogs no
> > longer w= orked 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: jav= a.net.SocketException: Software caused
> > connection abort: sock= et write error
> >
> > When trying to spot the error, I m= ade a peculiar observation:
> > I included a Phase Listener for th= e 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 call= ed twice sequentially from the same thread upon the
> > call of t= he dialog. I assume the first call is for the processing of
> > t= he base page and the second one for the dialog page.
> >
> &= gt; But starting with Trinidad 1.2.3, the phase listener is called *four* <= br>> > 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 t= he dialog with Internet
> > Explorer, only two sequential calls a= s with Trinidad 1.2.2 are being
> > executed.
> >
>= ; > I created a very simple test setup consisting of only two nearly emp= ty
> > pages (the base page and the dialog page), and a backing b= ean that
> > handles the closing of the dialog when the "close" l= ink 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.
> ><= br>> > Thanks,
> > Harald.
> >
>

She said what? About who? Shameful celebrity quotes on Search Star! = --_7c39940d-de8c-4f25-9e68-1f67e3d65050_--