Remove untrusted scripting support.

Remove untrusted scripting support.

BUG=82606
TEST=ppapi_tests,ppapi_unittests

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=92557

[dmichael (off chromium), 2011-07-14 04:54:01]

EXTERMINATE!!!!

[brettw, 2011-07-14 04:59:48]

http://codereview.chromium.org/7362012/diff/2001/ppapi/proxy/ppapi_proxy_test.h
File ppapi/proxy/ppapi_proxy_test.h (right):

http://codereview.chromium.org/7362012/diff/2001/ppapi/proxy/ppapi_proxy_test...
ppapi/proxy/ppapi_proxy_test.h:141: MessageLoop message_loop_;
Were these message loop additions on purpose?

[dmichael (off chromium), 2011-07-14 05:10:53]

On 2011/07/14 04:59:48, brettw wrote:
>
http://codereview.chromium.org/7362012/diff/2001/ppapi/proxy/ppapi_proxy_test.h
> File ppapi/proxy/ppapi_proxy_test.h (right):
> 
>
http://codereview.chromium.org/7362012/diff/2001/ppapi/proxy/ppapi_proxy_test...
> ppapi/proxy/ppapi_proxy_test.h:141: MessageLoop message_loop_;
> Were these message loop additions on purpose?
Yeah, sorry, should've mentioned, because it wasn't immediately obvious to me
why this started with this CL.  ppapi_unittests started failing; in particular,
at serialized_var_unittest.cc:59 when leaving scope, one of those SerializedVar
destructors made the ref count go to zero and it tried to send a message. That
seems to be what the test expects. But a DCHECK failed in
plugin_dispatcher.cc:107 (DCHECK(MessageLoop::current()) since the test didn't
have a valid message loop. I'm not sure why it did before; that's the only bit
that seemed a little scary to me.

The HostProxyTest message_loop_ may not be necessary, but I thought it likely
that we'd run in to a test failure some day under the same circumstances.

[brettw, 2011-07-14 15:27:48]

Maybe we should put the message loops in the Plugin/HostProxyTestHarness object
if all the tests might need them (or give hard-to-track down problems for people
writing new ones)?

[dmichael (off chromium), 2011-07-14 15:38:26]

On 2011/07/14 15:27:48, brettw wrote:
> Maybe we should put the message loops in the Plugin/HostProxyTestHarness
object
> if all the tests might need them (or give hard-to-track down problems for
people
> writing new ones)?
I don't think that would work for TwoWayTest, which has one of each kind of
harness as a member. That would make both MessageLoops get created on the main
thread, and the 2nd I think would fail a DCHECK.

I also thought the intent was that all the tests would be one of:
PluginProxyTest
HostProxyTest
TwoWayTest

and each of them has a MessageLoop for the main thread now, so I think all these
tests are safe (unless they define a new test base class or something).

But I'm open-minded if you have another suggestion. This 'stick a MessageLoop
member in the test class' pattern is something I stole from an IPC test.

[brettw, 2011-07-14 15:44:27]

On Thu, Jul 14, 2011 at 8:38 AM,  <dmichael@chromium.org> wrote:
> On 2011/07/14 15:27:48, brettw wrote:
>>
>> Maybe we should put the message loops in the Plugin/HostProxyTestHarness
>
> object
>>
>> if all the tests might need them (or give hard-to-track down problems for
>
> people
>>
>> writing new ones)?
>
> I don't think that would work for TwoWayTest, which has one of each kind of
> harness as a member. That would make both MessageLoops get created on the
> main
> thread, and the 2nd I think would fail a DCHECK.
>
> I also thought the intent was that all the tests would be one of:
> PluginProxyTest
> HostProxyTest
> TwoWayTest
>
> and each of them has a MessageLoop for the main thread now, so I think all
> these
> tests are safe (unless they define a new test base class or something).
>
> But I'm open-minded if you have another suggestion. This 'stick a
> MessageLoop
> member in the test class' pattern is something I stole from an IPC test.

I think what you have is fine, I was just hoping there might be an
easy way to make it harder to trip on this in the future.

Brett

[brettw, 2011-07-14 15:50:18]

Oh, sorry, I thought I already sent it.

LGTM