Re: Pepper Plugin Browsertests

14 views
Skip to first unread message

David Michael

unread,
Apr 2, 2015, 7:04:10 PM4/2/15
to Tommy Li, Bernhard Bauer, Lei Zhang, peppe...@chromium.org
+pepper-dev (FYI, public list)

Yes, see:
ppapi/tests/test*
...for individual tests
and:
chrome/test/ppapi/*
and
content/test/ppapi/*
...for where the GTEST parts live.

This has some info about running the tests manually if you choose:

On Thu, Apr 2, 2015 at 4:10 PM, Tommy Li <tomm...@google.com> wrote:
Hey guys,

Is there a test Pepper plugin we use for browsertests?

I ask because the Plugin Placeholder and Plugin Power Saver code needs some better automated tests, but I didn't find anywhere obvious to start looking in the codebase.

Tommy

Tommy Li

unread,
Apr 7, 2015, 8:06:41 PM4/7/15
to David Michael, Bernhard Bauer, Lei Zhang, peppe...@chromium.org
Hello,

I'm back for more advice. I would like to:
  • Overhaul the prerender_browsertest to use a Pepper plugin instead of a NPAPI plugin.
  • Add some tests to test the placeholder logic.
  • Add some tests to test the throttling heuristics, esp. with regard to partially obscured plugins.
I think I need a full browser to test this stuff end-to-end, so I think this needs to be a browser test, rather than a RenderViewTest. I have a few questions (and ideas) I wanted to run by you.
  1. What would be the Pepper equivalent for x-webkit-test-netscape? One thing I could do is modify the command line flags to --register-pepper-plugins="out/Debug/lib/libppapi_example_graphics_2d.so;application/x-ppapi-test"...

  2. What would be a good way of getting the state of the pepper plugin on the browser side? I actually have all the info I need on the PpapiPluginProcessHost object, since there's static methods such as DidCreateOutOfProcessInstance, OnPluginIstanceThrottleStateChange.

    The tricky part is that I don't know the actual instance id from the test code. Since I control the test page, if I only have one test plugin on it, can I assume there's only one? And then just add a PpapiPluginProcessHost::GetOneAndOnlyPluginInstanceForTest and a PpapiPluginProcessHost::GetOneAndOnlyPluginInstanceThrottleStateForTest?

    Another approach might be to make a custom test plugin that can answer Javascript calls. That was the approach taken by the old NPAPI test plugin. Since scripting is no longer supported, I assume I'd use the synchronous PPB_Messaging capability? I've been investigating this approach, but am a bit lost on how to implement this. How would the PPB_Messaging handler get the throttle state of the plugin?

  3. Any other misc. advice is appreciated too.
Thanks!

Tommy

David Michael

unread,
Apr 8, 2015, 11:04:31 AM4/8/15
to Tommy Li, Bernhard Bauer, Lei Zhang, peppe...@chromium.org
On Tue, Apr 7, 2015 at 6:06 PM, 'Tommy Li' via Pepper-dev <peppe...@chromium.org> wrote:
Hello,

I'm back for more advice. I would like to:
  • Overhaul the prerender_browsertest to use a Pepper plugin instead of a NPAPI plugin.
+1, that sounds like a good thing to do. 
  • Add some tests to test the placeholder logic.
  • Add some tests to test the throttling heuristics, esp. with regard to partially obscured plugins.
I think I need a full browser to test this stuff end-to-end, so I think this needs to be a browser test, rather than a RenderViewTest. I have a few questions (and ideas) I wanted to run by you.
I don't know anything about RenderViewTest. I do know that you can use Pepper in content_shell browser tests. See content/test/ppapi for examples. There are still examples in chrome/test/ppapi, partly because NaCl and Flash are features in Chrome but not content/. So you might not need a full-up Chrome browser_test.
  1. What would be the Pepper equivalent for x-webkit-test-netscape? One thing I could do is modify the command line flags to --register-pepper-plugins="out/Debug/lib/libppapi_example_graphics_2d.so;application/x-ppapi-test"...
Right, you can provide whatever MIME type you want to the "--register-pepper-plugins" flag, so in this case it's "application/x-ppapi-test". So it's up to the test to load the plugin 
 

  1. What would be a good way of getting the state of the pepper plugin on the browser side? I actually have all the info I need on the PpapiPluginProcessHost object, since there's static methods such as DidCreateOutOfProcessInstance, OnPluginIstanceThrottleStateChange.

    The tricky part is that I don't know the actual instance id from the test code. Since I control the test page, if I only have one test plugin on it, can I assume there's only one? And then just add a PpapiPluginProcessHost::GetOneAndOnlyPluginInstanceForTest and a PpapiPluginProcessHost::GetOneAndOnlyPluginInstanceThrottleStateForTest?
Something like that is probably fine, but I think most browser tests are mostly controlled from JavaScript, so you probably want to stick to that.

  1. Another approach might be to make a custom test plugin that can answer Javascript calls. That was the approach taken by the old NPAPI test plugin. Since scripting is no longer supported, I assume I'd use the synchronous PPB_Messaging capability? I've been investigating this approach, but am a bit lost on how to implement this. How would the PPB_Messaging handler get the throttle state of the plugin?
Yep, you could use the postMessageAndAwaitResponse if you like. Or you can use the async postMessage probably, depending on how your test is structured. And scripting is in fact still supported and we can't get rid of it (because Flash)...  it's just "Deprecated" because we don't want to expose it in NaCl or use it for anything else. But it would be OK to use for testing if it's most convenient. However you do it, some way of controlling from JavaScript is likely going to be desirable IMHO.

Caveat: I don't have much experience with browser tests outside of the Pepper ones.

  1. Any other misc. advice is appreciated too.
Thanks!

Tommy

On Thu, Apr 2, 2015 at 4:04 PM, David Michael <dmic...@chromium.org> wrote:
+pepper-dev (FYI, public list)

Yes, see:
ppapi/tests/test*
...for individual tests
and:
chrome/test/ppapi/*
and
content/test/ppapi/*
...for where the GTEST parts live.

This has some info about running the tests manually if you choose:

On Thu, Apr 2, 2015 at 4:10 PM, Tommy Li <tomm...@google.com> wrote:
Hey guys,

Is there a test Pepper plugin we use for browsertests?

I ask because the Plugin Placeholder and Plugin Power Saver code needs some better automated tests, but I didn't find anywhere obvious to start looking in the codebase.

Tommy


To unsubscribe from this group and stop receiving emails from it, send an email to pepper-dev+...@chromium.org.

Reply all
Reply to author
Forward
0 new messages