[JBoss JIRA] (RF-13160) Refactor the InputNumber* components into abstract classes
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13160?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13160:
------------------------------------
Thanx for the fix on the click event attributes.
+1 for the package change. I'll move it as part of this issue.
> Refactor the InputNumber* components into abstract classes
> ----------------------------------------------------------
>
> Key: RF-13160
> URL: https://issues.jboss.org/browse/RF-13160
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: component-input
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 1 hour, 30 minutes
> Remaining Estimate: 1 hour, 30 minutes
>
> The InputNumberSpinner and InputNumberSlider components are generated via xml in a faces-config.xml file. While this is clever, it means we have two components that are created differently from all the others, making them harder to manage. Additionally the xml is not conducive to refactoring, and the method relies on an xml format for shared attribute definitions, making it difficult to move forward with RF-12952.
> I propose re-implementing those components as Abstract components, like the majority of other RichFaces CDK components.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (RF-13161) rich:notifyMessages CSS incorrect on MyFaces 2.x
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13161?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13161:
-------------------------------
Labels: myfaces (was: )
> rich:notifyMessages CSS incorrect on MyFaces 2.x
> ------------------------------------------------
>
> Key: RF-13161
> URL: https://issues.jboss.org/browse/RF-13161
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.2.3.Final, 4.2.4, 4.3.0.Final, 4.3.1, 4.3.2, 4.3.3
> Reporter: John Yeary
> Labels: myfaces
> Attachments: myfaces-rf-example.zip, myfaces-rf-example.zip, RichfacesNotifyMessagesMyFaces.png
>
>
> The FacesMessage Severity levels do not match between Mojarra and MyFaces. As a result, the CSS styling for INFO messages are one level higher than they should be, and FATAL messages are unstyled.
> *Mojarra* - These represent values 0-3
> {noformat}
> /**
> * <p>Array of all defined values, ascending order of ordinal value.
> * Be sure you include any new instances created above, in the
> * same order.</p>
> */
> private static final Severity[] values =
> { SEVERITY_INFO, SEVERITY_WARN, SEVERITY_ERROR, SEVERITY_FATAL };
> {noformat}
> *MyFaces* - These represent values 1-4
> {noformat}
> /**
> * Message severity level indicating an informational message rather than an error.
> */
> public static final FacesMessage.Severity SEVERITY_INFO = new Severity("Info", 1);
> /**
> * Message severity level indicating that an error might have occurred.
> */
> public static final FacesMessage.Severity SEVERITY_WARN = new Severity("Warn", 2);
> /**
> * Message severity level indicating that an error has occurred.
> */
> public static final FacesMessage.Severity SEVERITY_ERROR = new Severity("Error", 3);
> /**
> * Message severity level indicating that a serious error has occurred.
> */
> public static final FacesMessage.Severity SEVERITY_FATAL = new Severity("Fatal", 4);
> {noformat}
> The *<rich:messages/>* component behaves correctly, and may be used as an alternative.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (RF-13161) rich:notifyMessages CSS incorrect on MyFaces 2.x
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13161?page=com.atlassian.jira.plugin.s... ]
Brian Leathem reassigned RF-13161:
----------------------------------
Assignee: Lukáš Fryč
[~lfryc], please assess and schedule accordingly.
> rich:notifyMessages CSS incorrect on MyFaces 2.x
> ------------------------------------------------
>
> Key: RF-13161
> URL: https://issues.jboss.org/browse/RF-13161
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.2.3.Final, 4.2.4, 4.3.0.Final, 4.3.1, 4.3.2, 4.3.3
> Reporter: John Yeary
> Assignee: Lukáš Fryč
> Labels: myfaces
> Attachments: myfaces-rf-example.zip, myfaces-rf-example.zip, RichfacesNotifyMessagesMyFaces.png
>
>
> The FacesMessage Severity levels do not match between Mojarra and MyFaces. As a result, the CSS styling for INFO messages are one level higher than they should be, and FATAL messages are unstyled.
> *Mojarra* - These represent values 0-3
> {noformat}
> /**
> * <p>Array of all defined values, ascending order of ordinal value.
> * Be sure you include any new instances created above, in the
> * same order.</p>
> */
> private static final Severity[] values =
> { SEVERITY_INFO, SEVERITY_WARN, SEVERITY_ERROR, SEVERITY_FATAL };
> {noformat}
> *MyFaces* - These represent values 1-4
> {noformat}
> /**
> * Message severity level indicating an informational message rather than an error.
> */
> public static final FacesMessage.Severity SEVERITY_INFO = new Severity("Info", 1);
> /**
> * Message severity level indicating that an error might have occurred.
> */
> public static final FacesMessage.Severity SEVERITY_WARN = new Severity("Warn", 2);
> /**
> * Message severity level indicating that an error has occurred.
> */
> public static final FacesMessage.Severity SEVERITY_ERROR = new Severity("Error", 3);
> /**
> * Message severity level indicating that a serious error has occurred.
> */
> public static final FacesMessage.Severity SEVERITY_FATAL = new Severity("Fatal", 4);
> {noformat}
> The *<rich:messages/>* component behaves correctly, and may be used as an alternative.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (RF-13161) rich:notifyMessages CSS incorrect on MyFaces 2.x
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13161?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13161:
------------------------------------
The MessageRenderer also uses the severity ordinal:
https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
so it's curious that this works for messages, but not for notifyMessages.
Thanks for reporting this John.
> rich:notifyMessages CSS incorrect on MyFaces 2.x
> ------------------------------------------------
>
> Key: RF-13161
> URL: https://issues.jboss.org/browse/RF-13161
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.2.3.Final, 4.2.4, 4.3.0.Final, 4.3.1, 4.3.2, 4.3.3
> Reporter: John Yeary
> Attachments: myfaces-rf-example.zip, myfaces-rf-example.zip, RichfacesNotifyMessagesMyFaces.png
>
>
> The FacesMessage Severity levels do not match between Mojarra and MyFaces. As a result, the CSS styling for INFO messages are one level higher than they should be, and FATAL messages are unstyled.
> *Mojarra* - These represent values 0-3
> {noformat}
> /**
> * <p>Array of all defined values, ascending order of ordinal value.
> * Be sure you include any new instances created above, in the
> * same order.</p>
> */
> private static final Severity[] values =
> { SEVERITY_INFO, SEVERITY_WARN, SEVERITY_ERROR, SEVERITY_FATAL };
> {noformat}
> *MyFaces* - These represent values 1-4
> {noformat}
> /**
> * Message severity level indicating an informational message rather than an error.
> */
> public static final FacesMessage.Severity SEVERITY_INFO = new Severity("Info", 1);
> /**
> * Message severity level indicating that an error might have occurred.
> */
> public static final FacesMessage.Severity SEVERITY_WARN = new Severity("Warn", 2);
> /**
> * Message severity level indicating that an error has occurred.
> */
> public static final FacesMessage.Severity SEVERITY_ERROR = new Severity("Error", 3);
> /**
> * Message severity level indicating that a serious error has occurred.
> */
> public static final FacesMessage.Severity SEVERITY_FATAL = new Severity("Fatal", 4);
> {noformat}
> The *<rich:messages/>* component behaves correctly, and may be used as an alternative.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (RF-13161) rich:notifyMessages CSS incorrect on MyFaces 2.x
by John Yeary (JIRA)
[ https://issues.jboss.org/browse/RF-13161?page=com.atlassian.jira.plugin.s... ]
John Yeary updated RF-13161:
----------------------------
Attachment: myfaces-rf-example.zip
This is a modified version of the original file which demonstrates the issue. This file contains an example workaround for resolving the icon images.
> rich:notifyMessages CSS incorrect on MyFaces 2.x
> ------------------------------------------------
>
> Key: RF-13161
> URL: https://issues.jboss.org/browse/RF-13161
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.2.3.Final, 4.2.4, 4.3.0.Final, 4.3.1, 4.3.2, 4.3.3
> Reporter: John Yeary
> Attachments: myfaces-rf-example.zip, myfaces-rf-example.zip, RichfacesNotifyMessagesMyFaces.png
>
>
> The FacesMessage Severity levels do not match between Mojarra and MyFaces. As a result, the CSS styling for INFO messages are one level higher than they should be, and FATAL messages are unstyled.
> *Mojarra* - These represent values 0-3
> {noformat}
> /**
> * <p>Array of all defined values, ascending order of ordinal value.
> * Be sure you include any new instances created above, in the
> * same order.</p>
> */
> private static final Severity[] values =
> { SEVERITY_INFO, SEVERITY_WARN, SEVERITY_ERROR, SEVERITY_FATAL };
> {noformat}
> *MyFaces* - These represent values 1-4
> {noformat}
> /**
> * Message severity level indicating an informational message rather than an error.
> */
> public static final FacesMessage.Severity SEVERITY_INFO = new Severity("Info", 1);
> /**
> * Message severity level indicating that an error might have occurred.
> */
> public static final FacesMessage.Severity SEVERITY_WARN = new Severity("Warn", 2);
> /**
> * Message severity level indicating that an error has occurred.
> */
> public static final FacesMessage.Severity SEVERITY_ERROR = new Severity("Error", 3);
> /**
> * Message severity level indicating that a serious error has occurred.
> */
> public static final FacesMessage.Severity SEVERITY_FATAL = new Severity("Fatal", 4);
> {noformat}
> The *<rich:messages/>* component behaves correctly, and may be used as an alternative.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (RF-13108) rich:calendar nested a4j:ajax event not firing
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13108?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-13108:
------------------------------------
[~bleathem], simple use-case with calendar, validator and ajax works fine.
I created a new sample in Metamer where I can reproduce different behavior of a4j:ajax and f:ajax with validators but I could not reproduce the case when ajax request would not be fired.
with a4j:ajax
# deploy Metamer (branch 4.3.x) and open http://localhost:8080/metamer/faces/components/richCalendar/rf-13108.xhtml
# select date in first calendar (e.g. 15 August 2013)
# select sooner date in second calendar (e.g. 2 August 2013), result: no message (a message next to second calendar should be displayed)
# click "Complete" button, result: no message
# click "Complete" button second time, result: a validation message next to second calendar
with f:ajax
# change a4j:ajax in first calendar in rf-13108.xhtml to f:ajax
# deploy Metamer (branch 4.3.x) and open http://localhost:8080/metamer/faces/components/richCalendar/rf-13108.xhtml
# select date in first calendar (e.g. 15 August 2013)
# select sooner date in second calendar (e.g. 2 August 2013), result: a validation message next to second calendar
> rich:calendar nested a4j:ajax event not firing
> ----------------------------------------------
>
> Key: RF-13108
> URL: https://issues.jboss.org/browse/RF-13108
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core, component-validators
> Affects Versions: 4.3.2
> Environment: jboss 7.1.3 richfaces 4.3.2.final, chrome
> Reporter: nathan dennis
> Assignee: Pavol Pitonak
> Labels: a4j:ajax, rich:calendar, rich:message
>
> nested a4j:ajax change event isn't functioning as expected. On "change" event, the expect result is that the value is moved into the target Date field of the backing bean. When using a4j:ajax, this does not happen.
> After speaking with ppitonak he believe that the order of the ajax with relation to the validators was import. however after closer inspection, the value wasn't making back to the bean even when the event was fired even with the order reversed.
> Logically the first date should be submitted to the backing bean on change even and made available for validation in the second dates validator. works with f:ajax.. doesnt work with a4j:ajax.
> {code}
> Request URL:http://oasis.monarchnc.org:10001/oasis/screening/edit.xhtml?cid=2
> Request Method:POST
> Status Code:200 OK
> Request Headersview source
> Accept:*/*
> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
> Accept-Encoding:gzip,deflate,sdch
> Accept-Language:en-US,en;q=0.8
> Connection:keep-alive
> Content-Length:870
> Content-type:application/x-www-form-urlencoded;charset=UTF-8
> Cookie:JSESSIONID="gOuCLop-DL7U6D3fbNhptHmw.slave:server-three"; csfcfc=11Xfn_12Xfn; __utma=69432588.533798156.1374674467.1374674467.1374674467.1; __utmz=69432588.1374674467.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); org.monarchnc.commandcenter.location=1; org.monarchnc.commandcenter.security=NDNlZGQ3ZDU3NjIxYzI4YjM4YzZlOTM0YzQ3ZjAxYWQ_
> Faces-Request:partial/ajax
> Host:oasis.monarchnc.org:10001
> Origin:http://oasis.monarchnc.org:10001
> Referer:http://oasis.monarchnc.org:10001/oasis/screening/edit.xhtml?cid=2&id=143&dsRid=197&windowId=-9720
> User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22
> Query String Parametersview sourceview URL encoded
> cid:2
> Form Dataview sourceview URL encoded
> create:create
> create:medrecordnumber:
> create:patientName:Ritchard Trickle
> create:patientPhone:
> create:patientEmail:
> create:startTimeOverrideInputDate:30/7/13 04:24 PM
> create:startTimeOverrideInputCurrentDate:07/2013
> create:endTimeOverrideInputDate:01/8/13 05:58 PM
> create:endTimeOverrideInputCurrentDate:08/2013
> create:screeningBeanScreeningProviderValue:
> create:screeningBeanScreeningProviderInput:dennis, nathan
> javax.faces.ViewState:-4869776129569305131:8783263118910249789
> javax.faces.source:create:startTimeOverride
> javax.faces.partial.event:change
> javax.faces.partial.execute:create:startTimeOverride @component
> javax.faces.partial.render:@component
> javax.faces.behavior.event:change
> org.richfaces.ajax.component:create:startTimeOverride
> rfExt:null
> AJAX:EVENTS_COUNT:1
> javax.faces.partial.ajax:true
> Response Headersview source
> Cache-Control:no-cache
> Connection:close
> Content-Type:text/xml;charset=UTF-8
> Date:Thu, 01 Aug 2013 15:59:07 GMT
> Server:Apache-Coyote/1.1
> Transfer-Encoding:chunked
> X-Powered-By:JSF/2.0
> {code}
> {code:xml}
> <?xml version='1.0' encoding='UTF-8' ?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <ui:composition xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:ui="http://java.sun.com/jsf/facelets"
> xmlns:c="http://java.sun.com/jsp/jstl/core"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:rich="http://richfaces.org/rich"
> template="/resources/scaffold/pageTemplate.xhtml">
> <f:metadata>
> <f:viewParam name="id" value="#{screeningBean.id}"/>
> </f:metadata>
> <ui:define name="main">
> <h:form id="create">
>
> <h:panelGrid columnClasses="label,component,required" columns="3">
> <h:outputLabel for="startTimeOverride" value="Start Time Override:"/>
> <rich:calendar value="#{screeningBean.screening.beginTime}" id="startTimeOverride"
> popup="true" datePattern="dd/M/yy hh:mm a" required="true"
> showApplyButton="true" >
> <f:validateRequired />
> <a4j:ajax event="change" bypassUpdates="#{true}"/>
> </rich:calendar>
> <rich:message for="startTimeOverride" ajaxRendered="true" />
> <h:outputLabel for="endTimeOverride" value="End Time Override:" />
> <rich:calendar value="#{screeningBean.screening.endTime}" id="endTimeOverride"
> popup="true" datePattern="dd/M/yy hh:mm a"
> showApplyButton="true" >
> <f:validateRequired />
> <f:validator validatorId="dateRangeValidator" />
> <rich:validator />
> <a4j:ajax event="change" bypassUpdates="#{true}"/>
> </rich:calendar>
> <rich:message for="endTimeOverride" ajaxRendered="true" />
> </h:panelGrid>
> <div class="buttons">
> <a4j:commandButton value="Complete"
> action="#{screeningBean.updateScreening(2)}"
> execute="@form"
> onclick="this.disabled=true; var that = this; setTimeout(function() that.disabled=false;},500);"
> styleClass="btn btn-primary btn-primary-a4j" />
> </div>
> </h:form>
> </ui:define>
> </ui:composition>
> {code}
> {code:title=DateRangeValidator.java}
> /**************************************************************
> * Copyright (c) 2012 - 2013, Monarch, All rights reserved.
> *
> * @author Nathan Dennis
> *
> */
> package org.monarchnc.view.validators;
> import java.text.DateFormat;
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.faces.application.FacesMessage;
> import javax.faces.component.UIComponent;
> import javax.faces.component.UIInput;
> import javax.faces.context.FacesContext;
> import javax.faces.validator.FacesValidator;
> import javax.faces.validator.Validator;
> import javax.faces.validator.ValidatorException;
> import javax.persistence.EntityManager;
> import org.apache.deltaspike.core.api.provider.BeanProvider;
> import org.monarchnc.view.ScreeningBean;
> // TODO: Auto-generated Javadoc
> /**
> * The Class DateRangeValidator.
> */
> @FacesValidator("dateRangeValidator")
> public class DateRangeValidator implements Validator {
>
>
> /* (non-Javadoc)
> * @see javax.faces.validator.Validator#validate(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.Object)f
> */
> public void validate(final FacesContext ctx, final UIComponent component, final Object value) throws ValidatorException {
>
> ScreeningBean screeningBean = BeanProvider.getContextualReference(screeningBean.class, false);
>
> Date date =(Date) value;
> if(screeningBean.getScreening().getBeginTime() != null && date != null)
> if(!date.after(screeningBean.getScreening().getBeginTime())){
> throw new ValidatorException(new FacesMessage(FacesMessage.SEVERITY_ERROR,"End Date must be after Start Date!!.\n","End Date must be after Start Date!!\n"));
>
> }
>
>
> }
> }
> {code}
> {code:title=ScreeningBean.java}
> @Named
> @Transactional
> @ConversationScoped
> public class ScreeningBean implements Serializable{
> Screening screening = new Screening();
> public Class<? extends ViewConfig> claim(){
> if (this.conversation.isTransient())
> {
> this.conversation.begin();
> }...
> }
> public Screening getScreening() {
> return screening;
> }
> public void setScreening(Screening screening) {
> this.screening = screening;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (RF-11546) collapsiblePanel does not reevaluate expanded attribute on ajax render
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-11546?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak resolved RF-11546.
--------------------------------
Resolution: Cannot Reproduce Bug
> collapsiblePanel does not reevaluate expanded attribute on ajax render
> ----------------------------------------------------------------------
>
> Key: RF-11546
> URL: https://issues.jboss.org/browse/RF-11546
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.0.0.Final
> Reporter: u j
> Assignee: Pavol Pitonak
>
> If a rich:collapsiblePanel is rerendered via ajax, the expanded attribute is not re-evaluated.
> {code}
> <rich:collapsiblePanel toggleListener="#{bean.toggle}"
> expanded="#{bean.open}" switchType="ajax"
> onswitch="#{bean.render ? 'load();' : ''} >
> {code}
> The bean.render method is called, the open method is not (verified with the debugger).
> So e.g. the panel is opened by click, some other action changes the (session) bean property open to false and then an action ajax-rerenders the panel, the panel is still open instead of closed.
> Only on a page GET reload is the panel closed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (RF-11546) collapsiblePanel does not reevaluate expanded attribute on ajax render
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-11546?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-11546:
------------------------------------
I could not reproduce in neither 4.3.4.Final nor in 5.0.0-SNAPSHOT. This issue was reported for 4.0.0.Final so probably it's outdated.
> collapsiblePanel does not reevaluate expanded attribute on ajax render
> ----------------------------------------------------------------------
>
> Key: RF-11546
> URL: https://issues.jboss.org/browse/RF-11546
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.0.0.Final
> Reporter: u j
> Assignee: Pavol Pitonak
>
> If a rich:collapsiblePanel is rerendered via ajax, the expanded attribute is not re-evaluated.
> {code}
> <rich:collapsiblePanel toggleListener="#{bean.toggle}"
> expanded="#{bean.open}" switchType="ajax"
> onswitch="#{bean.render ? 'load();' : ''} >
> {code}
> The bean.render method is called, the open method is not (verified with the debugger).
> So e.g. the panel is opened by click, some other action changes the (session) bean property open to false and then an action ajax-rerenders the panel, the panel is still open instead of closed.
> Only on a page GET reload is the panel closed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (RF-13139) popupPanel duplicated if double clicking links for opening popup
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13139?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13139:
-------------------------------
Environment:
* Tomcat 7, JBoss EAP 6.1.0
* Richfaces 4.3.1.Final, 5.0.0-SNAPSHOT
* Mojarra 2.2.0, 2.1.19
* Chrome 29
was:tomcat 7, Richfaces 4.3.1.Final, Spring, JSF Mojarra 2.2.0
> popupPanel duplicated if double clicking links for opening popup
> ----------------------------------------------------------------
>
> Key: RF-13139
> URL: https://issues.jboss.org/browse/RF-13139
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.3.1, 5.0.0.Alpha1
> Environment: * Tomcat 7, JBoss EAP 6.1.0
> * Richfaces 4.3.1.Final, 5.0.0-SNAPSHOT
> * Mojarra 2.2.0, 2.1.19
> * Chrome 29
> Reporter: Valiantsin Shukaila
> Assignee: Brian Leathem
> Labels: popupPanel, richfaces
> Attachments: RF-13139.zip
>
>
> If you create a link/button/jsFunction that should render popup panel and open it after that and will try to double click this link the two instances of the same popup panel will appear. And you will be able to close only one of them. The other will remain on the page forever.
> I've attached zip with maven and eclipse project that can be used for reproducing the issue.
> I tested on Tomcat 7.0.41.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months