[JBoss JIRA] (RF-12841) Tooltip: JavaScript Error with showDelay and partial update
by Lutz Ulrich (JIRA)
[ https://issues.jboss.org/browse/RF-12841?page=com.atlassian.jira.plugin.s... ]
Lutz Ulrich updated RF-12841:
-----------------------------
Workaround Description:
It seems, hiding the tooltip before the AJAX request is submitted prevents the script error
{code}
<a4j:commandLink onclick="#{rich:component('tooltipid')}.hide()" ....)
{code}
was:
It seems, hiding the tooltip before the AJAX request is submitted prevents the script error ( <a4j:commandLink onclick="#{rich:component('tooltipid')}.hide()" ....)
> Tooltip: JavaScript Error with showDelay and partial update
> -----------------------------------------------------------
>
> Key: RF-12841
> URL: https://issues.jboss.org/browse/RF-12841
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.0.Final, 4.3.1
> Environment: Mojarra 2.1.17
> Reporter: Lutz Ulrich
> Priority: Minor
> Labels: testcase_provided
> Fix For: 5-Tracking
>
>
> rich:tooltip causes script error when showDelay is used and the tooltip is updated due to a JSF request.
> Console log of Firefox:
> TypeError: tooltip.popup is null
> tooltip.popup.show(tooltip.saveShowEvent); in tooltip.js (line 245)
> The error comes in all browsers I tested with.
> {code}
> <a4j:commandLink action="#{richTabMinimizer.toggle}" render="@this">
> <h:graphicImage library="org.richfaces.images"
> name="#{richTabMinimizer.expanded ? 'triangleUp.png' : 'triangleDown.png'}"/>
>
> <rich:tooltip followMouse="false" showDelay="1000">
> #{richTabMinimizer.expanded ? 'close' : 'expand'}
> </rich:tooltip>
> </a4j:commandLink>
>
> {code}
> (Its a stripped down example. The actual content of my tool-tip holds more text.)
> Note that my 'richTabMinimizer.toggle' bean toggles some GUI stuff and its property 'expanded' is switched from true to false and vice versa.
> You may probably replace it with anything to reproduce the error.
> Probably the tool-tip tries to show after the HTML elements have already been updated.
> It's no serious error. Nevertheless, its ugly.
> I guess it is not unusual to have a tool-tip (with a showDelay) on a command.
> But often, users will click the command just after the mouse entered the command.
> Maybe this issue report is a duplicate of RF-8652, but in contrast to 8652, I do not refer to open tooltips.
> For me, it would be sufficient if the script error is avoided.
> I do not expect the updated tooltip to show after the delay.
--
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, 4 months
[JBoss JIRA] (RF-12841) Tooltip: JavaScript Error with showDelay and partial update
by Lutz Ulrich (JIRA)
[ https://issues.jboss.org/browse/RF-12841?page=com.atlassian.jira.plugin.s... ]
Lutz Ulrich updated RF-12841:
-----------------------------
Workaround Description:
It seems, hiding the tooltip before the AJAX request is submitted prevents the script error ( <a4j:commandLink onclick="#{rich:component('tooltipid')}.hide()" ....)
Workaround: Workaround Exists
> Tooltip: JavaScript Error with showDelay and partial update
> -----------------------------------------------------------
>
> Key: RF-12841
> URL: https://issues.jboss.org/browse/RF-12841
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.0.Final, 4.3.1
> Environment: Mojarra 2.1.17
> Reporter: Lutz Ulrich
> Priority: Minor
> Labels: testcase_provided
> Fix For: 5-Tracking
>
>
> rich:tooltip causes script error when showDelay is used and the tooltip is updated due to a JSF request.
> Console log of Firefox:
> TypeError: tooltip.popup is null
> tooltip.popup.show(tooltip.saveShowEvent); in tooltip.js (line 245)
> The error comes in all browsers I tested with.
> {code}
> <a4j:commandLink action="#{richTabMinimizer.toggle}" render="@this">
> <h:graphicImage library="org.richfaces.images"
> name="#{richTabMinimizer.expanded ? 'triangleUp.png' : 'triangleDown.png'}"/>
>
> <rich:tooltip followMouse="false" showDelay="1000">
> #{richTabMinimizer.expanded ? 'close' : 'expand'}
> </rich:tooltip>
> </a4j:commandLink>
>
> {code}
> (Its a stripped down example. The actual content of my tool-tip holds more text.)
> Note that my 'richTabMinimizer.toggle' bean toggles some GUI stuff and its property 'expanded' is switched from true to false and vice versa.
> You may probably replace it with anything to reproduce the error.
> Probably the tool-tip tries to show after the HTML elements have already been updated.
> It's no serious error. Nevertheless, its ugly.
> I guess it is not unusual to have a tool-tip (with a showDelay) on a command.
> But often, users will click the command just after the mouse entered the command.
> Maybe this issue report is a duplicate of RF-8652, but in contrast to 8652, I do not refer to open tooltips.
> For me, it would be sufficient if the script error is avoided.
> I do not expect the updated tooltip to show after the delay.
--
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, 4 months
[JBoss JIRA] (RF-13098) Regression: mediaOutput broken for CDI MediaData beans
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/RF-13098?page=com.atlassian.jira.plugin.s... ]
Marek Schmidt commented on RF-13098:
------------------------------------
That doesn't help for CDI beans, as you still get
Unauthorized deserialization attempt; org.jboss.weld.bean.proxy.util.SerializableClientProxy
I assume a workaround would be to add this one and others to a custom resource-serialization.properties, but it is still a regression.
Also, how should I know if org.jboss.weld.bean.proxy.util.SerializableClientProxy or other classes that may be required are safe to be added to the whitelist?
> Regression: mediaOutput broken for CDI MediaData beans
> ------------------------------------------------------
>
> Key: RF-13098
> URL: https://issues.jboss.org/browse/RF-13098
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.3
> Reporter: Marek Schmidt
> Labels: regression
>
> https://issues.jboss.org/browse/RF-13089 introduced a regression for a4j:mediaOutput component
> Having a
> {code}
> <a4j:mediaOutput element="img" cacheable="true" session="true" createContent="#{mediaBean.paint}" value="#{mediaData}" mimeType="image/jpeg"/>
> {code}
> with mediaData being a CDI bean, e.g.
> {code}
> @javax.inject.Named("mediaData")
> @javax.enterprise.context.RequestScoped
> public class MediaData implements Serializable
> {code}
> the following exception occurs:
> {code}10:39:27,997 SEVERE [org.richfaces.log.Resource] (http-/127.0.0.1:8080-1) Input error for deserialize data : java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.bean.proxy.util.SerializableClientProxy
> at org.richfaces.util.LookAheadObjectInputStream.resolveClass(LookAheadObjectInputStream.java:93) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1704) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1342) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_25]
> at org.richfaces.util.Util.decodeObjectData(Util.java:237) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.DefaultCodecResourceRequestData.getData(DefaultCodecResourceRequestData.java:97) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:337) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:156) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.1.19.1.Final-redhat-1.jar:2.1.19.1.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {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, 4 months
[JBoss JIRA] (RF-13093) extendedDataTable column resizing and reordering not working on transient (stateless) views
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13093?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13093:
------------------------------------
As we resolve the issues in RichFaces 5, we'll assess whether it's a good candidate to backport to RichFaces 4.
> extendedDataTable column resizing and reordering not working on transient (stateless) views
> -------------------------------------------------------------------------------------------
>
> Key: RF-13093
> URL: https://issues.jboss.org/browse/RF-13093
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.2
> Environment: GlassFish 3.1.2.2 with Mojarra 2.1.23
> Reporter: Salvo Isaja
> Labels: jsf22
> Fix For: 5.0.0.Alpha2
>
>
> When turning on transient (stateless) views in recent Mojarra versions (as per JSF 2.2 specification, to my best understanding), using request scoped backing beans, javax.faces.ViewState becomes the constant "stateless". Column resizing and reordering in extendedDataTable causes an Ajax request to the server, but in this case an invalid response is sent, containing only:
> {code:xml}
> <?xml version='1.0' encoding='UTF-8'?>
> <partial-response></partial-response>
> {code}
> This causes an exception in {{jsf.js}} because the partial-response element has no children and no further JavaScript processing happens in the view until the page is reloaded. In the non-transient view case, I see a {{change}} element updating only the ViewState is returned, instead.
> Other features seem to work pretty well in stateless mode, by the way.
> Thanks
--
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, 4 months
[JBoss JIRA] (RF-13093) extendedDataTable column resizing and reordering not working on transient (stateless) views
by Salvo Isaja (JIRA)
[ https://issues.jboss.org/browse/RF-13093?page=com.atlassian.jira.plugin.s... ]
Salvo Isaja commented on RF-13093:
----------------------------------
Any chance for a workaround for 4.3.x/JSF 2.1? Thanks
> extendedDataTable column resizing and reordering not working on transient (stateless) views
> -------------------------------------------------------------------------------------------
>
> Key: RF-13093
> URL: https://issues.jboss.org/browse/RF-13093
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.2
> Environment: GlassFish 3.1.2.2 with Mojarra 2.1.23
> Reporter: Salvo Isaja
> Labels: jsf22
> Fix For: 5.0.0.Alpha2
>
>
> When turning on transient (stateless) views in recent Mojarra versions (as per JSF 2.2 specification, to my best understanding), using request scoped backing beans, javax.faces.ViewState becomes the constant "stateless". Column resizing and reordering in extendedDataTable causes an Ajax request to the server, but in this case an invalid response is sent, containing only:
> {code:xml}
> <?xml version='1.0' encoding='UTF-8'?>
> <partial-response></partial-response>
> {code}
> This causes an exception in {{jsf.js}} because the partial-response element has no children and no further JavaScript processing happens in the view until the page is reloaded. In the non-transient view case, I see a {{change}} element updating only the ViewState is returned, instead.
> Other features seem to work pretty well in stateless mode, by the way.
> Thanks
--
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, 4 months
[JBoss JIRA] (RF-13098) Regression: mediaOutput broken for CDI MediaData beans
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13098?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13098:
------------------------------------
Have you read any of the release announcements arounf the 4.3.3.Final patch release? You'll want to implement org.richfaces.resource.SerializableResource in that backing bean.
See:
http://www.bleathem.ca/blog/2013/07/richfaces-CVE-2013-2165.html
> Regression: mediaOutput broken for CDI MediaData beans
> ------------------------------------------------------
>
> Key: RF-13098
> URL: https://issues.jboss.org/browse/RF-13098
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.3
> Reporter: Marek Schmidt
> Labels: regression
>
> https://issues.jboss.org/browse/RF-13089 introduced a regression for a4j:mediaOutput component
> Having a
> {code}
> <a4j:mediaOutput element="img" cacheable="true" session="true" createContent="#{mediaBean.paint}" value="#{mediaData}" mimeType="image/jpeg"/>
> {code}
> with mediaData being a CDI bean, e.g.
> {code}
> @javax.inject.Named("mediaData")
> @javax.enterprise.context.RequestScoped
> public class MediaData implements Serializable
> {code}
> the following exception occurs:
> {code}10:39:27,997 SEVERE [org.richfaces.log.Resource] (http-/127.0.0.1:8080-1) Input error for deserialize data : java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.bean.proxy.util.SerializableClientProxy
> at org.richfaces.util.LookAheadObjectInputStream.resolveClass(LookAheadObjectInputStream.java:93) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1704) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1342) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_25]
> at org.richfaces.util.Util.decodeObjectData(Util.java:237) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.DefaultCodecResourceRequestData.getData(DefaultCodecResourceRequestData.java:97) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:337) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:156) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.1.19.1.Final-redhat-1.jar:2.1.19.1.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {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, 4 months