Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1011466

Summary: PoupPanel doesn't disappear when rendered="false" and rerender it.
Product: [Retired] JBoss Enterprise WFK Platform 2 Reporter: Takayuki Konishi <tkonishi>
Component: RichFacesAssignee: Brian Leathem <bleathem>
Status: CLOSED CURRENTRELEASE QA Contact: Pavol Pitonak <ppitonak>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.3.0CC: jhuska, jpallich
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-10 14:13:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Takayuki Konishi 2013-09-24 10:57:35 UTC 
Created attachment 802167 [details]
reproducer

Description of problem:


If you use the richfaces popupPanel in the default domElementAttachment="body" mode it will not disappear under specific conditions.

 
    <h:body title="page 1">
        <a4j:outputPanel id="myPanel">
            <rich:popupPanel domElementAttachment="body" show="true" rendered="#{test.showPopup}">
                <h:form>
                    <a4j:commandButton action="#{test.switchPopup()}" value="switch off" render="myPanel"/>
                </h:form>
            </rich:popupPanel>

            <h:form>
                <a4j:commandButton action="#{test.switchPopup()}" value="switch on" render="myPanel"/>
            </h:form>
        </a4j:outputPanel>
    </h:body>

In Richfaces 3.3.x, on the other hand, there was a component cleanup system (memory.js _cleanComponentNodes) which was responsible to remove components after ajax calls if the component was removed from the current view.
Therefore the above example (revert popupPanel to modalPanel) works in RF3.3.4.Final.

Note:
In case domElementAttachment="parent", it will show the other JSF2 bug where the view state was lost, therefore you must click the action button twice to really call the function.


Version-Release number of selected component (if applicable):

RichFaces 4.2.3.Final

How reproducible: 100%


Steps to Reproduce:

1. get, extract and build attached rf4_2_3-popuppanel.zip
2. deploy target/testcase-rf4_2_3.war to a app server.
3. open one of these URLs
 - http://localhost:8080/test/popup_body.faces
 - http://localhost:8080/test/popup_form.faces
 - http://localhost:8080/test/popup_parent.faces
4. click "switch on" button
5. click "switch off" button

Actual results:

popupPanel is closed.

Expected results:

popupPanel is still open.

Additional info:
the only one that works is the popup_parent one, because the reRender will remove the panel implicit because it updates the dom where the panel lies inside. The other two methods don't work because the panel was moved to a different place in dom.
Comment 2 JBoss JIRA Server 2013-09-24 21:10:06 UTC 
Brian Leathem <bleathem> made a comment on jira RF-13216

Quoting from the Richfaces 4 docs:

http://docs.jboss.org/richfaces/latest_4_X/Component_Reference/en-US/html_single/#sect-Component_Reference-richpopupPanel-Showing_and_hiding_the_pop-up

{quote}
Placement

The <rich:popupPanel> component is usually rendered in front of any other objects on the page. This is achieved by attaching the component to the <body> element of the page, and setting a very high "z-index" (the stack order of the object). This approach is taken because relatively-positioned elements could still overlap the pop-up panel if they exist at higher levels of the DOM hierarchy, even if their z-index is less than the <rich:popupPanel> component.
If the <rich:popupPanel> is to participate in submitting child components/behaviors, then a form element must be nested within the <rich:popupPanel>. Alternatively, if no overlapping elements exist, the <rich:popupPanel> component can be reattached to its original DOM element by setting domElementAttachment to either parent or form.
{quote}

This clearly states that using _domElementAttachment="body"_ is for use cases where the popup does not "participate in submitting child components/behaviors" ie. AJAX.

for the described use case:

# set _domElementAttachment="form"_ and have both the popup and the calling page in the same form.
# If separate forms are preferable, try setting _domElementAttachment="body"_ and using a nested form in the popupPanel.  When the popup is closed refresh the page with a full JSF page load, rather than an AJAX update.
Comment 3 JBoss JIRA Server 2013-09-25 09:03:59 UTC 
Markus Schulz <msc> made a comment on jira RF-13216

additional problem:
domElementAttachment="body" will break the ajax actions of the "outer" form.
consider the following example:

<h:form>
  ...
  <rich:popupPanel>
    <h:form>
       <!-- local form needed for actions if we use default behaviour and move the panel in DOM -->
       ...
    </h:form>
  </rich:popupPanel
  ...

  <a4j:commandbutton action="test.action()"/>
</h:form>

submit the commandButton will not work, because the DOM of the outer form now contains two hidden fields of "javax.faces.encodedURL" and the javascript code to fetch the submit-url  (jsf.js) will fail in this scenario.
Comment 4 JBoss JIRA Server 2013-09-26 15:40:11 UTC 
Brian Leathem <bleathem> made a comment on jira RF-13216

additional problem:
domElementAttachment="body" will break the ajax actions of the "outer" form.
consider the following example:

{code}
<h:form>
  ...
  <rich:popupPanel>
    <h:form>
       <!-- local form needed for actions if we use default behaviour and move the panel in DOM -->
       ...
    </h:form>
  </rich:popupPanel
  ...

  <a4j:commandbutton action="test.action()"/>
</h:form>
{code}

submit the commandButton will not work, because the DOM of the outer form now contains two hidden fields of "javax.faces.encodedURL" and the javascript code to fetch the submit-url  (jsf.js) will fail in this scenario.
Comment 5 JBoss JIRA Server 2013-09-27 13:26:57 UTC 
Juraj Húska <jhuska> made a comment on jira RF-13216

I have tried to reproduce the issue on [this|https://github.com/richfaces/richfaces-qa/tree/RF-13216] branch.
* reproducer facelet [here|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/webapp/components/richPopupPanel/rf-13216.xhtml]
* managed bean [here|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/java/org/richfaces/tests/metamer/bean/issues/RF13216.java]

I am able to reproduce the second mentioned issue: 
Invoking request from the outside form is broken. However, I can reproduce the issue with {{h:commandButton}}. When using {{a4j:commandButton}} from outside form, the action method is called.

Steps to reproduce:
# load the reproducer page: http://localhost:8080/metamer/faces/components/richPopupPanel/rf-13216.xhtml
# click on the button: "outside full page"
# see that no message is logged in the server console
# when clicking on the button: "outside Ajax" - there is message logged on the console

Should I do something more ?
Comment 6 JBoss JIRA Server 2013-09-27 13:29:00 UTC 
Juraj Húska <jhuska> made a comment on jira RF-13216

I have tried to reproduce the issue on [this|https://github.com/richfaces/richfaces-qa/tree/RF-13216] branch.
* reproducer facelet [here|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/webapp/components/richPopupPanel/rf-13216.xhtml]
* managed bean [here|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/java/org/richfaces/tests/metamer/bean/issues/RF13216.java]

I am able to reproduce the second mentioned issue: 
Invoking request from the outside form is broken. However, I can reproduce the issue with {{h:commandButton}}. When using {{a4j:commandButton}} from outside form, the action method is called and an AJAX request is made.

Steps to reproduce:
# load the reproducer page: http://localhost:8080/metamer/faces/components/richPopupPanel/rf-13216.xhtml
# click on the button: "outside full page"
# see that no message is logged in the server console - also no request is fired - full request expected
# when clicking on the button: "outside Ajax" - there is message logged on the console - expected AJAX request is fired

Should I do something more ?
Comment 7 JBoss JIRA Server 2013-09-30 07:05:56 UTC 
Juraj Húska <jhuska> made a comment on jira RF-13216

I have tried to reproduce the issue on [this|https://github.com/richfaces/richfaces-qa/tree/RF-13216] branch.
* reproducer facelet [here|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/webapp/components/richPopupPanel/rf-13216.xhtml]
* managed bean [here|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/java/org/richfaces/tests/metamer/bean/issues/RF13216.java]

I am able to *reproduce the second mentioned issue*: 
Invoking request from the outside form is broken. However, I can reproduce the issue with {{h:commandButton}}. When using {{a4j:commandButton}} from outside form, the action method is called and an AJAX request is made.

Steps to reproduce:
# load the reproducer page: http://localhost:8080/metamer/faces/components/richPopupPanel/rf-13216.xhtml
# click on the button: "outside full page"
# see that no message is logged in the server console - also no request is fired - full request expected
# when clicking on the button: "outside Ajax" - there is message logged on the console - expected AJAX request is fired

Should I do something more ?
Comment 8 JBoss JIRA Server 2013-10-15 16:06:12 UTC 
Brian Leathem <bleathem> made a comment on jira WFK2-221

Why is this scheduled for 2.4.0?  WFK 2.4.0 will include RichFaces 4.3.4 which will not include a patch for this issue.  rather this issue should be targetting WFK 2.5, and we'll provide the customer with a one-off-patch earlier if required.
Comment 9 JBoss JIRA Server 2013-10-15 16:20:30 UTC 
Marek Schmidt <maschmid> made a comment on jira WFK2-221

We just follow the CDW process... If you don't want to have it WFK 2.4, just do Devel reject.
Comment 10 JBoss JIRA Server 2013-10-15 16:52:20 UTC 
Marek Schmidt <maschmid> made a comment on jira WFK2-221

We just follow the CDW process... If you don't want to have it WFK 2.4, just do Devel reject.   (the content of WFK is not defined by component versions, it is defined by the CDW process ;)
Comment 11 JBoss JIRA Server 2013-10-15 19:21:50 UTC 
Brian Leathem <bleathem> made a comment on jira RF-13216

Thanks [~jhuska], however the second related issue is a well-known JSF 2 bug ([JAVASERVERFACES_SPEC_PUBLIC-790|https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790]).  If you could please verify the primary issue of this bug report, whereby a popupPanel doesn't disappear when its _rendered_ attribute is set to _false_ and then rendered vai an ajax update.

When investigating, please also try wrapping the popupPanel in a panelGroup, and targeting that panelGroup with an ajax render.
Comment 12 JBoss JIRA Server 2013-10-16 10:43:15 UTC 
Juraj Húska <jhuska> made a comment on jira RF-13216

I can reproduce the original issue as well. The popup panel can not be closed when firstly not rendered, then rendered via an ajax update.

However, as you stated in [this|https://issues.jboss.org/browse/RF-13216?focusedCommentId=12807033&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12807033] comment, it does not seem to be a bug, but rather expected behavior.

I have pushed the facelets reproducing the issue [here|https://github.com/richfaces/richfaces-qa/tree/RF-13216]. Please see:
* [orginal reporter sample|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/webapp/components/richPopupPanel/rf-13216-original.xhtml] - *issue reproduced*
* [using also panelGroup sample|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/webapp/components/richPopupPanel/rf-13216-withPanelGroup.xhtml] - *issue reproduced*
* [domElementAttachment to form sample|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/webapp/components/richPopupPanel/rf-13216-domElementAttachmentForm.xhtml] - *as expected, it works* - the popup panel can be closed
* [separate forms sample|https://github.com/richfaces/richfaces-qa/blob/RF-13216/metamer/application/src/main/webapp/components/richPopupPanel/rf-13216-separateForms.xhtml] - *does not work*, it should according the already referenced comment.

Please, let me know if I should update some of the facelets anyhow ?

Steps to reproduce:
# load the original reproducer: http://localhost:8080/metamer/faces/components/richPopupPanel/rf-13216-original.xhtml
# click on the button: "switch on"
# an ajax update is made and the popup panel is rendered
# click switch off
# an ajax call is fired, however, the respective {{action}} method of the button is not called, thus the popup panel is not closed
Comment 13 JBoss JIRA Server 2013-10-18 03:58:39 UTC 
Brian Leathem <bleathem> made a comment on jira RF-13216

The reported use case of hiding a popupPanel using the _rendered_ attribute and an ajax call initiated from withtin the popupPanel can be resolved with the following code sample:

{code}
        <h:form>
            <a4j:outputPanel id="myPanel">
                <rich:popupPanel domElementAttachment="parent" show="true" rendered="#{test.showPopup}">
                    <a4j:commandButton action="#{test.switchPopup()}" value="switch off" render="myPanel"/>
                </rich:popupPanel>

                <a4j:commandButton action="#{test.switchPopup()}" value="switch on" render="myPanel"/>
            </a4j:outputPanel>
        </h:form>
{code}

Some key points to remember:
# Neither _domElementAttachment="body"_ nor _domElementAttachment="form"_ work, as the popupPanel is re-located in the DOM, thus is no longer a child of outputPanel and does not participate in the ajax render.
# There is no nested form in the popupPanel.  Nested forms are not supported in HTML, likewise they are not supported in JSF.
# The recommended means of showing/hiding a popupPanel is to leave it rendered, and show/hide it via the javascript API.

IMO the default value for the _domElementAttachment_ attribute should be _parent_, with an override as required for exceptional circumstances.  If this were the case, the popupPanel would behave as other JSF panel components, and this issue would not have arisen.
Comment 15 JBoss JIRA Server 2013-11-15 07:21:40 UTC 
Brian Leathem <bleathem> made a comment on jira RF-13216

[~tkonishi] can we close this issue?
Comment 16 JBoss JIRA Server 2013-12-24 00:58:37 UTC 
Brian Leathem <bleathem> updated the status of jira RF-13216 to Resolved
Comment 17 Jiri Pallich 2014-01-10 14:13:30 UTC 
The issue has not been present in the WFK 2.4.
Comment 18 JBoss JIRA Server 2014-03-20 07:49:34 UTC 
Pavol Pitonak <ppitonak> updated the status of jira WFK2-221 to Closed