Wt

Hey Ravil,

What you see on the server is a stack trace of the JS exception that happened client side. It contains useful hints on what went wrong. This is escpecially interesting to monitor the problems that occur on the client in a production environment.

A more interactive method is to set the 'JavaScript debug options' flag to true in wt_config.xml, and run the application in a browser window with the debugger open. The exception will not be caught by Wt, so you can use the debugger to break when the uncaught exception is thrown.

Best regards,

Wim.

Hi Wim,

Could not find description what is the format of wt_config.xml file in the reference documentation. Examples do not have such an option as "JavaScript debug options".

Does the attached wt_config.xml file have right format?

Looks like somehow I could find where the exception is thrown - attached JavaScript.txt file. It has just one line where an exception was thrown, where the exception position is on column # 10337 (I split line into 2 at this position for convenience to find it), does not tell me anything what is wrong on C side of things. The JavaScript code is o.set[0], perhaps variable o is not initialized (null), but what that object o means, unknown.

I guess this is all generated by Wt, and I have no idea what C class should I look at.

Looks like debugging of the client side code is nightmare. I am stuck at this. I even don't know rendering what view is it throwing an exception.

Tried to completely eliminate GridLayout, putting things into BoxLayouts instead, did not help.

What do you do in situations like this? what is your approach to resolve issues like this for customers who has support contract? You take copy of their application and try to reproduce and resolve in your side? Or you connect remotely to customer's machine and debug remotely? How do you navigate on such a complex JavaScript code?

Thank you, Ravil

The wt_config.xml that ships with Wt contains the full description of all configurable options. It is by default installed in /etc/wt or c:/witty.

Chrome inspector has a button that organises the JS in a readable way. It looks like '{}'. But the backtrace contains probably the most interesting information...

Best regards,

Wim.

Hi Wim,

I installed binaries for Windows, which comes as a zip file, not as installer, so I don't have c:/witty folder. Under the unzipped folder there are wt_xonfig.xml files under examples folder, but they have only a few fields defined relevant to these examples. If I install full source, then I should have it I guess.

But now the problem is not in xml file, I can see the Java Script source in the Chrome debugger.

Yes, most parts of the JS code organized nicely in readable way. But the line where the exception is thrown has length 14159 (the attached in previous message file has that single line of code), which is not readable at all.

But even readability of the JS code is not big deal. I can see the call stack trace, all variables values, which is good.

I can see even why the exception is thrown - it is because variable "o" does not have "set" member. So from the debugger point of view, it provides all the information developer needs.

The biggest problem now is how to correlate this as you say the most interesting information with the C side? Number of calls from the stack trace is 7, on that single long line of code.

I don't ask to resolve this particular problem for me, just would like to know, what is the common methodology in general? If I select Witty for production, then these kinds of problems will require quick resolution. Would really appreciate if you could provide some general directions.

Thank you, Ravil

Since last post I did some progress. I found where the corresponding JS file is located, and looks like found where the error is.

Looks like JS files are built into the binary as a result of compilation, so in order to apply fix made the JS file, I need to rebuild Wt.

Discovered that the JS code on Chrome debugger is not readable because it is compressed into min.js. If I define WT_DEBUG_JS, maybe I will have uncompressed JS code in Chrome debugger.

One thing unclear yet, what tool is used to create min.js files.

Ravil --- I also have the same error as you (Cannot read property of undefined) after upgrading to 3.3.4RC1, but do not know where you fixed the JS File in Wt. Can you give more details? Thanks.

-Ethan

Hi Ethan,

Thinking, that I found how to fix it, I downloaded latest source code from Git, rebuilt with my change in .js file, and did not have have any error. Then in order to verify that my change actually made difference, I rolled back the change, rebuilt, and surprisingly did not get any errors again. So I guess the latest version in GIT has no issue.

Therefore I would recommend you get the latest source code and rebuild.

Hi all ---

Thanks Ravil for your input. It turns out for me I had some custom code:

setJavaScriptMember( "wtResize", jsString );

Removing it solved my problem. I guess 3.3.4RC1 doesn't like anyone touching wtResize?

~ ~ ~

For others reading this, Wim mentioned earlier the Chrome debugger has a '{}' to pretty up the JS code...it is located under 'Sources' tab at the bottom left corner of the editor. I also turned on 'Async' at the call stack. Both super useful.

-Ethan

Hey,

W.r.t. setting a custom wtResize function giving an error, do you have more suggestions on how to reproduce the problem and did you check if the current got version has the same issue?

Koen

Hi Koen,

I had the issue with version 3.3.4 (I was using binaries, did not build myself at that time).

I had a page with multiple layers of nesting, like grid is in the box, which is in turn in another box. And I had resize calls on widgets (standard call, not used custom Java script).So I think the problem was related to resizing.

When I got current by that time version from GIT, and re-built it, the issue could not be reproduced anymore. So I would assume that the latest version should not have the issue.

Regards, Ravil