[PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.

[Erich Hoover]

On Sun, Jan 23, 2011 at 11:32 AM, Jacek Caban <jacek at codeweavers.com> wrote:
> On 1/20/11 6:40 PM, Erich Hoover wrote:
>> On Thu, Jan 20, 2011 at 4:00 AM, Jacek Caban<jacek at 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 at mines.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CommandPassthruTest.diff
Type: text/x-patch
Size: 15431 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110124/c708bd96/attachment.bin>