On 29 September 2010 13:45, Jacek Caban jacek@codeweavers.com wrote:
On 9/29/10 2:30 PM, Reece Dunn wrote:
On 29 September 2010 11:39, Jacek Cabanjacek@codeweavers.com wrote:
On 9/28/10 9:37 PM, Reece Dunn wrote:
On 28 September 2010 15:14, Jacek Cabanjacek@codeweavers.com wrote:
I am interested in helping out to improve this area -- my aim is to not require the `winetricks ie6` command to get some of these applications (specifically the Big Fish Games client) to a usable state.
Therefore, I am wondering if anyone knows where the best place is to start looking (e.g. known areas of missing functionality) or how to debug applications (and interpret WINEDEBUG output) to identify where the issues are.
There is no single answer. You want mshtml debug channel for most cases. If the problem is with embedding document in an app, then shdocvw is also useful. If you have scripts that don't work (and we use jscript for them), then jscript debug channel is the answer. If you have a problem with loading document, I'd add urlmon,wininet channel.
After some digging around, there appears to be some issues with the jscript.dll implementation:
$ trace:jscript:DispatchEx_QueryInterface (0x1dad2d0)->(IID_IDispatchJS 0x33d5e8) $ trace:jscript:DispatchEx_AddRef (0x1dad2d0) ref=7 $ trace:jscript:prop_get L"SWFObject" ret {VT_EMPTY} $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=6 $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=5 $ fixme:jscript:new_expression_eval throw TypeError The new_expression_eval fixme is because V_VT(&constr) == VT_EMPTY.
Now SWFObject is defined in a<script> file, but there are various script files. For example, given a html file containing:
<script src="a.js"></script> <script src="b.js"></script> with a.js:
function SWFObject() { this.x = 5; }
and b.js:
var swf = new SWFObject(); // appears to be erroring here alert(swf.x); Is this supported currently in Wine, or am I going down the wrong track?
It's a known regression. A hack from bug 24365 should work around it.
OK. Thanks. I'll use that to proceed on the issues with Big fish Games.
That's all fine, but all this won't help with fixing Big Fish Games.
I understand this -- I am thinking of improving things for when errors occur.
The problem is probably somewhere else and the question is why the script takes code path resulting in an exception (and even if it's supposed to do so, current exception handling is probably good enough for it).
The problem with the current wine tip is that 'fixme:jscript:new_expression_eval throw TypeError' line. Since this is triggered in the main script (not in a try ... catch block) it will not get handled properly.
BTW, the script seems to mess with a flash plugin, that won't work with jscript as we'd have to handle ActiveX controls in MSHTML. That's a hard problem.
Aha! That is likely what is calling the TypeError fixme.
a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function
That's not the right place. See exception_test in api.js for exceptions test. It's obviously not testing OnScriptError, but most tests should go there.
This is what step (1) is testing:
exception_test(function() {new null;}, "TypeError", ...);
which is great if you have something like:
<script>try { new null; } catch (e) { ... }</script>
but not something like:
<script>new null;</script>
This triggers (http://msdn.microsoft.com/en-us/library/shbz8x82%28v=VS.85%29.aspx) the IActiveScriptSite_OnScriptError callback notification. This is what I intend on testing in the dlls/jscript/tests/activex.c tests as I need to inspect that call when executing this type of unhandled/uncaught exception, which is what will happen in the Big Fish Games client.
- Reece