Actions
Bug #4523
openJSignal unmarshalling fails with latest chrome version (45.0)
Start date:
10/23/2015
Due date:
% Done:
0%
Estimated time:
Description
The exception listed at the bottom of this issue description got thrown in specific when scrolling in a WTableView that was displayed in a zoomed out chrome tab.
Further testing showed that:
- the same exception is thrown when the tab is zoomed in
- the exception is not thrown in firefox
This is seems to be caused by the fact that the javascript event arguments passed by chrome are now non-integer values wether they still are for Firefox.
This has been tested only with jWt v3.3.3 but may affect newer versions.
Chrome User agent string:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36
Firefox User agent string:
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0
Thrown exception and stack trace:
eu.webtoolkit.jwt.WtException: JSignal: scrolled: could not interpret argument 1 ('117.77778089782346') as type java.lang.Integer
at eu.webtoolkit.jwt.AbstractJSignal.unMarshal(AbstractJSignal.java:76)
at eu.webtoolkit.jwt.JSignal4.processDynamic(JSignal4.java:130)
at eu.webtoolkit.jwt.WebSession.processSignal(WebSession.java:1830)
at eu.webtoolkit.jwt.WebSession.notifySignal(WebSession.java:1937)
at eu.webtoolkit.jwt.WebSession.notify(WebSession.java:470)
at eu.webtoolkit.jwt.WApplication.notify(WApplication.java:2838)
at eu.webtoolkit.jwt.WebSession.handleRequest(WebSession.java:1553)
at eu.webtoolkit.jwt.WtServlet.doHandleRequest(WtServlet.java:361)
at eu.webtoolkit.jwt.ServletApi.handleRequest(ServletApi.java:27)
at eu.webtoolkit.jwt.ServletApi3.doHandleRequest(ServletApi3.java:98)
at eu.webtoolkit.jwt.WtServlet.handleRequest(WtServlet.java:255)
at eu.webtoolkit.jwt.WtServlet.doPost(WtServlet.java:271)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:395)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:250)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Updated by Wim Dumon about 9 years ago
Hello Gaetan,
Browsers have indeed changed their behaviour wrt this point. If you upgrade your JWt version to the 3.3.5 release candidate, this problem will go away.
Best regards,
Wim.
Actions