I found some JSNI code that was inadvertently doing a javascript object
clone of a GWT object. Fixing that solved my problem. Although it's still
not clear why it would only trigger in optimized code and not draft compile
or why no exceptions were being captured in the console. Oh well, it's
The profile entries that pointed to JavaScriptException in obfuscated
output now points to a lambda in detailed output, so I think that's a red
herring. I commented out the lamba in question and those profile entries
went away, but the problem persists, so I don't think it's the lamba itself.
I'm not getting anything on the console logs and I've verified that I've
got an uncaught exception handler set. However, when I profile during this
frozen state, all profile entries seem to lead to this:
d,com.google.gwt.core.client.JavaScriptException::name,com.google.gwt.core.
I'll do some more diagnostics on it come Monday.
Thanks for the advice...
On Saturday, October 1, 2016, Mike Warne wrote:
> Do you have any JavaScript exceptions in your browser console? Sometimes
> an exception will cause important code to be skipped, causing your app
Do you have any JavaScript exceptions in your browser console? Sometimes an
exception will cause important code to be skipped, causing your app to be
unresponsive.
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this
The problem happens at runtime during use of the application. Things seem
to work OK at first, but after certain actions are taken (seemingly related
to some DOM event handlers, but I'm not sure) the application stops
responding to the mouse or keyboard. The only thing I am sure of at the
moment
Hi,
when the problem happened? In compilation process or in application loading
and execution?
If the problem is in compilation process, you could try '-optimize 8' (or
lower optimization level) as gwt compiler parameter. There are some
situations which cause gwt compile takes so long.
You
Any advice on how to trouble shoot code that runs fine in SDM but causes
lockups when run in full compiled mode? Using the -draftCompile flag fixes
it in compiled mode too. This suggests that something in the optimizations
isn't playing nice with the code, but I'm at a bit of a loss for how to