On Sun, Jan 23, 2011 at 11:32 AM, Jacek Caban jacek@codeweavers.com wrote:
On 1/20/11 6:40 PM, Erich Hoover wrote:
On Thu, Jan 20, 2011 at 4:00 AM, Jacek Cabanjacek@codeweavers.com wrote:
- ok(status& success_flag, "OLECMDID_STOP not enabled/supported: %08x\n", status);
You could test the exact value here: ok(status == ...)
I was trying to avoid adding some conditional todo_wine calls
Hiding differences between Wine and Windows in tests is the worst thing you can do. When one is trying to find a bug, tested parts of implementation are much less suspicious than not or poorly tested. If you know about more such things in the patch, please fix them. You don't write the test to pass on your implementation. You write it to know the right implementation.
I would say that testing the mask is not about hiding differences, it makes it clear that this particular test is meant to demonstrate whether a specific feature is available. At some point you have to make a trade-off between making a particular test completely comprehensive or having it be clear exactly what is being tested. In this particular component there are a lot of things that are not yet implemented, so it's a little difficult to add a self-contained test for a feature without it ballooning into a bunch of unrelated issues. There are two other such "issues" I have become aware of with the current implementation that could be added as tests, but I would say that they both belong in separate patches (if you want them at all):
1) The IOleCommandTarget is cached when the WebBrowser is initialized (rather than being requested each time it is used) 2) The document is initialized much earlier on native than it is in Wine
My goal here is to implement (as well as I can) a single feature that I've had sitting in my stack of unsubmitted patches, I'm not trying to implement everything in this component in one fell swoop. If that's really what it's going to take to get this feature implemented then I can take the time to implement more, but it'll take me a while and I'd really like to move this item off of my plate so I can clean up some of my other unsubmitted patches before they become too far out of sync.
(for some reason native does not respond with "supported", even though it does in the mshtml tests), please see if you like the attached better.
Or it proves that it's not a simple forward to mshtml?
It's possible that they masked the supported flag out, especially since all of the examples I've seen on MSDN check for the enabled flag rather than the supported flag. However, I doubt that they copy-pasted the mshtml code and then made changes to it. I'd say that even if they did it'd be better to forward to mshtml and discover if there are any differences (and where they are) as people test applications that use this functionality.
We still have them in separated functions you've called test_QueryStatusWB and test_ExecWB. We most likely will want more tests on WebBrowser instance without container's IOleCommandTarget, and it would be nice if we could reuse test_CommandTargetPassthru for that (well, the name would be better more generic as well).
Sorry, for some reason I was a bit dense and didn't catch exactly what you were planning here. Please see if the attached is more to your liking, the test bot results are available here: https://testbot.winehq.org/JobDetails.pl?Key=8575
Erich Hoover ehoover@mines.edu