Bug 806065 - Pressing Esc key in jBPM Console throws exception
Summary: Pressing Esc key in jBPM Console throws exception
Keywords:
Status: ASSIGNED
Alias: None
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM Console
Version: BRMS 5.3.0.GA
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: ---
Assignee: Kris Verlaenen
QA Contact: Jiri Locker
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-22 19:57 UTC by Jiri Locker
Modified: 2022-11-15 23:14 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
Esc exception (67.94 KB, image/png)
2012-03-22 19:57 UTC, Jiri Locker
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 815726 0 unspecified VERIFIED Do not obfuscate bpm-console client side stacktraces to improve supportability and bugzilla reports 2023-05-31 22:25:02 UTC

Internal Links: 815726

Description Jiri Locker 2012-03-22 19:57:25 UTC
Created attachment 572073 [details]
Esc exception

Description of problem:
Esc key is often used to abort/cancel application dialogs. I'm often tempted to close the confirmation message after starting a process this way. There are many other dialogs the user might try to close using keybord. Hitting Esc always results in exception printed in the Messages panel.

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

How reproducible:
always

Steps to Reproduce:
1. log in into jBPM Console
2. press Esc key
  
Actual results:
Exception is thrown.

Expected results:
No exception should be thrown. If there is an active dialog, it should be closed.

Additional info:
see attached screenshot

Comment 1 Geoffrey De Smet 2012-04-24 13:00:45 UTC
I am trying to de-obfuscate the stacktrace, but without much success. Apparently the classes used in that stacktrace aren't in bpm-console itself:

2012-04-24 14:58:26,576 [ERROR] Communication Error<br/>Additional details:<br/> None
java.lang.Throwable:
null
    at Unknown.dA(JsArrayString.java:42)
    at Unknown.dv(StackTraceCreator.java:366)
    at Unknown.Vu(Throwable.java:46)
    at Unknown.yWc(ClientMessageBusImpl.java:879)
    at Unknown.nN(Request.java:287)
    at Unknown.VN(RequestBuilder.java:393)
    at Unknown.anonymous(XMLHttpRequest.java:258)
    at Unknown.kz(Impl.java:146)
    at Unknown.anonymous(Impl.java:56)

Comment 2 Jiri Locker 2012-04-24 16:27:10 UTC
ClientMessageBusImpl sounds like Errai.

Comment 3 Geoffrey De Smet 2012-04-24 16:41:17 UTC
Yes, it's Errai 1.1.Final.
Problem is De-obfuscated that stacktrace doesn't help much: Errai 1.1's ClientMessageBusImpl effectively eats the server-side exception.

What I need is the server side log, which will have the real stacktrace.

Comment 4 Geoffrey De Smet 2012-04-25 11:37:34 UTC
Porcelli and me finally got bpm-console and jbpm-gwt-console to build from source and run.

However, some things to notice:
- there is no server side log of this exception. So either:
-- the server eats the exception
-- the client uses the wrong url.
Problem is that ClientMessageBusImpl even eats the status code.

Comment 5 Geoffrey De Smet 2012-04-25 14:13:42 UTC
The bpm-console doesn't support GWT hosted mode (not as part of jbpm-console anyway), so I 've hacked the errai jars to get some more info what goes wrong:

2012-04-25 16:01:22,747 [ERROR] Communication Error<br/>Additional details:<br/> None
java.lang.Throwable:
ge0ffrey hack statusCode (0) text ()
    at Unknown.$fillInStackTrace(StackTraceCreator.java:147)
    at Unknown.fillInStackTrace(StackTraceCreator.java:387)
    at Unknown.Throwable_1(Throwable.java:46)
    at Unknown.onResponseReceived_9(ClientMessageBusImpl.java:879)
    at Unknown.$fireOnResponseReceived(Request.java:287)
    at Unknown.onReadyStateChange_0(RequestBuilder.java:395)
    at Unknown.anonymous(XMLHttpRequest.java:287)
    at Unknown.entry0(Impl.java:214)
    at Unknown.anonymous(Impl.java:57)

Unfortunately that states the impossible: the HTTP statusCode is 0, which by definition always 1xx, 2xx, 3xx, 4xx or 5xx.
The text is empty.

Comment 6 Geoffrey De Smet 2012-04-25 14:40:51 UTC
Since the exception stacktrace is a dead end because there's no way to figure out what code activated the request or even what the request was, I 've looked at it from the other direction:

- There is only one usage of addKey*() in bpm-console: org.jboss.bpm.console.client.LoginView#createForm(). That code cannot cause this as it does nothing on an ESCAPE key down or pressed event.
- All other code that involves the word "key" isn't related to keyboard events.

This leads me to believe, it might be something in the libraries that we use.


Note You need to log in before you can comment on or make changes to this bug.