myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <>
Subject Re: [Trinidad] js issue while handling PPR inside a tr:panelPopup
Date Fri, 22 Feb 2008 19:52:57 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Done - see <a class="moz-txt-link-freetext" href=""></a><br>
-- Renzo<br>
Andrew Robinson wrote:
  <pre wrap="">Good. Do you want to file a bug and upload a patch?

A timeout of 0 or 1 ms should be sufficient.


On Fri, Feb 22, 2008 at 9:51 AM, Renzo Tomaselli
<a class="moz-txt-link-rfc2396E" href="">&lt;;</a>
  <blockquote type="cite">
    <pre wrap=""> Andrew, yes - using setTimeout solves the problem. Just put:

         if (_agent &amp;&amp; _agent.isIE)
             window.setTimeout("document.getElementById('" + refocusId +
"').focus()", 1000);

 Btw I noticed a similar problem today in a different context. I had a popup
list (non a tr:panelPopup) to be shown as a suggestion list upon clicking a
link. All done through PPR and I needed to call focus() to preselect the
first item as well as catching onBlur to hide the list.
 Once again, no problems on FF, while on IE this call returned ok, but the
very first time no popup was shown. Once more - commenting out the focus
call solved the problem. But even doing it a bit later through setTimeout
was ok.

 -- Renzo

 Andrew Robinson wrote:
 I am wondering if this ought to be called in a window setTimeout. Any
way you can modify the code locally and attempt to see if that helps?

On Fri, Feb 22, 2008 at 1:30 AM, Renzo Tomaselli
<a class="moz-txt-link-rfc2396E" href="">&lt;;</a>

 Yes, I followed the PPR response handling on FF/Firebug - but there all is
 Then I investigated on IE 6/7 by means of placing alerts everywhere. There
is no return from calling focus(), although no errors are reported - even on
IE 7 with IE developer toolbar activated.

 -- Renzo

 Andrew Robinson wrote:
 Hmmm, you say this is during the PPR application?

I think there is a bug in IE that causes exceptions to be thrown if
setFocus is called from the PPR "thread"


On Thu, Feb 21, 2008 at 3:04 AM, Renzo Tomaselli
<a class="moz-txt-link-rfc2396E" href="">&lt;;</a>

 Hi, I have a panelPopup containing a number of links with
 partialSubmit="true". The panel itself is enclosed into a
 panelGroupLayout bound to a bean.
 This binding allows to define the enclosing panel as a PPR target
 through addPartialTarget(), no matter which links triggers it.
 So the overall structure is roughly like this:

 &lt;tr:panelGroupLayout id="modalWrapper" binding="#{bean.panel}"&gt;
 &lt;tr:panelPopup id="modal" position="centered" modal="true"&gt;
 &lt;tr:commandLink id="next" action="#{}"

 all of this works fine on FF. However it does not on IE 6/7. The very
 first time the panel is created, but any following click on links does
 not refresh panel contents.
 After some js debugging - I noticed that in Page.js, method
 _handlePprResponseFragment() - there is a focus action on the link
 itself (which is recorded as being active):

 if (refocusId) {
 activeNode = doc.getElementById(refocusId);
 if (activeNode &amp;&amp; activeNode.focus) {
 activeNode.focus(); // !!!!!

 on IE there is no return from focus(), so that the rest of the panel
 fragments are not rendered. No errors, though.
 If I comment out the focus() call, everything works as expected.

 -- Renzo

  <pre wrap=""><!---->


View raw message