Corrupt widgetset

Hi All,

We have an intermittent problem in both IE and Chrome with corrupt widget set, and I’d like to hear if anyone else have had this problem.

When this problem happen, we never get past the initial spinning wheel when loading the app.
We get around it by clearing the cache and reloading.

With the DevTools open in Chrome, I can see in the console that we have a syntax error in “ptsmcWidgetset-0.js”
This seems to be a file generated out of the C572B950C80EA8903DD90317E1723C1D.cache.js ?

The code snippet in ptsmcWidgetset-0.js that fails looks like this
On line 2 there is a syntax error, and the rest doesn’t look all that good either…

function com_google_gwt_user_client_ui_UIObject_updatePrimaryAndDependentStyleNames__Lcom_google_gwt_dom_client_Element_2Ljava_lang_String_2V(elem, newPrimaryStyle){
var classes = (elemtyle){
if (!elyle);im_user= (e.gle_gwt_dom_client_EleM_Lcom_googletors_AbstractRendererCogwt_dom
p.removeChild(node)gle_oldyle);im_userLcomwt_dom[0 nodegle_oldyle);im_userLe nodoldyle);im_user;
ifaryAwt_dom[0 com_gyle);im_user++) {
gle_i co1 (!Lcomwt_dom;
if i < nf i!!node && gle_nStri0Lcomwt_dom[i node;
nStri0entExcep>oldyle);im_userLe nta?cStri0echarAt(oldyle);im_userLe )ptiot_usta?cStri0eient_Inpoldyle);im_user)ptioght +(mwt_dom[i com_gyle);im_user +?cStri0efunctityl(oldyle);im_userLe )tePrimaryent_EleM_Lcom_gcomwt_dom;j) {(’ 'l_defineClass__Lcom_google_gwt_core_client_JavaScriptObject_2Lcom_google_gwt_core_client_JavaScriptObject_2Lcom_google_gwt_core_client_JavaScriptObject_2Lcom_google_gwt_core_client_JavaScriptObject_2(1253, 624, $intern_16, com_ec_os_widgetset_checkbox_c0_client_rende37lickableIObject_2Ljava_lang_Sasses = (elemtyle){kboxRendererConnependentStyleNames__Lcom_google_gwtbleIObject_2Ljava_lang_Sasses = (elemtyle){(ct$setStyleName__Lcom_google_gwt_user_client_ui_UIObjeci_UIObject_2Ljava_lang_String_2V(this$static, styleSuffix){
com_google_gwt_user_client_ject_$setStylererCellRt_2Ljava_lang_Sasses = (elemtyle){kboxRendererConnependentStyleNames__Lcom_google_gwtbleIObje_lang_Sasses = (elemtyle){(ct_$seName__Lcom_google_gwt_user_client_ui_UIObjeci_UIObje_lang_String_2V(this$static, styleSuffix){
com_google_gwt_user_client_ject_$senderer_2 = t_2I(this$statIkboxRendererConnependentStyleNames__Lcom_google_gwt = t_2I(this$statI(sVisible__Lcom_google_gwt_dom_client_Element_2Z((cobject_2I(this$static){
return com_google_gwt_dom_client_Elementenderer_2 = t_2I(ta_lang_IkboxRendererConnependentStyleNames__Lcom_google_gwt = t_2I(ta_lang_I(sVisible__Lcom_google_gwt_dom_client_Element_2Z((cobject_2I(tis$static){
return com_google_gwt_dom_client_Elementenderer_2 = ), style);

[/code]When we reload and it works, the same code snippet looks like this:

function com_google_gwt_user_client_ui_UIObject_updatePrimaryAndDependentStyleNames__Lcom_google_gwt_dom_client_Element_2Ljava_lang_String_2V(elem, newPrimaryStyle){ var classes = (elem.className || '').split(/\s+/); if (!classes) { return; } var oldPrimaryStyle = classes[0] ; var oldPrimaryStyleLen = oldPrimaryStyle.length; classes[0] = newPrimaryStyle; for (var i = 1, n = classes.length; i < n; i++) { var name_0 = classes[i] ; name_0.length > oldPrimaryStyleLen && name_0.charAt(oldPrimaryStyleLen) == '-' && name_0.indexOf(oldPrimaryStyle) == 0 && (classes[i] = newPrimaryStyle + name_0.substring(oldPrimaryStyleLen)); } elem.className = classes.join(' '); } Googling updatePrimaryAndDependentStyleNames I see that the content of this function is supposed to be a bit of native code, so it should always appear just like above.

I should add that this is with Wildfly 8.2 as web server.
We have compiled the widgetset with style PRETTY instead of the default obfuscated.

The C572B950C80EA8903DD90317E1723C1D.cache.js file is 12M large and around 93K lines.
The function with the problem is about 146K into the file, at line 1203

We have now identified that the server delivers the pre-gzipped version of C572B950C80EA8903DD90317E1723C1D.cache.js from the server.
When we extract the gz file from the chrome cache and compare with the actual file from the deploy directory, we get 2 differences:

At 0x5ff6 the cached version has two extra bytes: 0x0D0A (carriage return + line feed )
At the end, the cached version has replaced the last two bytes with 26 other bytes

A corrupted gz file can explain the strange result, but I would have expected Chrome and IE to check the CRC?
When I try to uncompress the corrupt gz file from the cache with TotalCommander, it complains about CRC error.

One uncertainty is that we had to do some massaging to extract the file from the chrome cache, so we might have introduced some of this ourselves, but if we accept that this is the correct content, where can this corruption come from?

This seems to have been a bug in Wildfly.
When we recently upgraded it to version 9.0.2 the problem went away.

Hi Guttorm,

I’m experiencing the identical issue and also running on Wildfly 8.2.0. I was wondering, now that you’ve been on 9.0.2 for a while, has the problem remained resolved?

Hi David,

Yes, problem remain solved.
We have since upgraded to wildfly 10, but we had about 3 months on wildfly 9 without problems.