Hi,
The current state of support for the Internet Explorer components in Wine is good, but there are applications that don't work with it because they are dependent on more of the functionality provided by Internet Explorer via the WebBrowser control.
I have had a scan through some of the mshtml code, and see various things not handled -- such as the onload handler of the HTMLBody element -- but I am not very familiar with this area.
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.
Thanks, - Reece
Hi Reece,
On 9/28/10 2:59 PM, Reece Dunn wrote:
Hi,
The current state of support for the Internet Explorer components in Wine is good, but there are applications that don't work with it because they are dependent on more of the functionality provided by Internet Explorer via the WebBrowser control.
I have had a scan through some of the mshtml code, and see various things not handled -- such as the onload handler of the HTMLBody element -- but I am not very familiar with this area.
onload is handled properly on body element, it's just getter/setter that is a stub. It's a trivial one line patch that implements them. The fact that they are stubs means that I've never seen them used in apps I was working on.
Most MSHTML APIs are trivial Gecko API wrappers. They are easy to implement, the only problem is that there are really many functions to implement. I implement only ones that are needed for real apps. The hard part of MSHTML is in the few APIs that are not just wrappers and not directly exposed parts like loading the document.
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.
Jacek
On 28 September 2010 15:14, Jacek Caban jacek@codeweavers.com wrote:
Hi Reece,
On 9/28/10 2:59 PM, Reece Dunn wrote:
Hi,
The current state of support for the Internet Explorer components in Wine is good, but there are applications that don't work with it because they are dependent on more of the functionality provided by Internet Explorer via the WebBrowser control.
I have had a scan through some of the mshtml code, and see various things not handled -- such as the onload handler of the HTMLBody element -- but I am not very familiar with this area.
onload is handled properly on body element, it's just getter/setter that is a stub. It's a trivial one line patch that implements them. The fact that they are stubs means that I've never seen them used in apps I was working on.
Most MSHTML APIs are trivial Gecko API wrappers. They are easy to implement, the only problem is that there are really many functions to implement. I implement only ones that are needed for real apps. The hard part of MSHTML is in the few APIs that are not just wrappers and not directly exposed parts like loading the document.
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?
- Reece
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.
Jacek
On 29 September 2010 11:39, Jacek Caban jacek@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.
I am also planning on improving wine's behaviour in this regard on error (to assist in tracking down regressions/unimplemented behaviour). The details will likely change as I progress on this. Specifically:
1/ new_expression_eval @ dlls/jscript/engine.c -- FIXME: throw TypeError
a/ add dlls/jscript/tests/api.js test -- 'new null;' throws TypeError b/ call throw_type_error @ dlls/jscript/error.c
==> I have a patch for this, just need to run it on winetestbot to verify Windows behaviour.
2/ Test unhandled exceptions when parsing scripts
a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function b/ modify parse_script_a to support expected error code tests c/ call parse_script_a(script, "new null;", error) i/ thrown error -- throw TypeError(); ii/ unexpected -- new null; iii/ parse error -- new ; iv/ caught error does not call ActiveScriptSite_OnScriptError -- try { new null; } catch (e) {} d/ if FAILED(parse_script_a) i/ check if ActiveScriptSite_OnScriptError is called ii/ test values on IActiveScriptError object e/ implement calling ActiveScriptSite_OnScriptError in wine's jscript correctly
3/ ActiveScriptSite_OnScriptError @ dlls/mshtml/script.c
a/ add dlls/mshtml/tests/script.c test ==> mshtml.ActiveScriptSite_OnScriptError fires an onerror event b/ implement the behaviour in wine
4/ Real-world test case:
a/ add a new dlls/mshtml/tests/jserror.html file: <script> called_onerror = false; function trigger_error(){ throw SomeError(); } </script> <body onerror="called_onerror = true;" onload="trigger_error(); ok(called_onerror);"> </body>
5/ test/investigate the default mshtml onerror behaviour
- Reece
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. 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).
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.
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.
Jacek
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
On 9/29/10 3:03 PM, Reece Dunn wrote:
On 29 September 2010 13:45, Jacek Cabanjacek@codeweavers.com wrote:
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.
Sure, but if you want to test new_expression_eval behavior, it's enough and better as the code is cleaner. OnScriptError is a separate problem.
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.
You have run.c for that. activex.c is, as the name suggests, for testing ActiveXObject-related stuff.
Jacek
-
Jacek Caban -
Reece Dunn