I think the problem is that the change assumes that if WIDEVINE_CDM_AVAILABLE, it is shipped with the browser and not _only_ a component. That happens to be the case for branding == Chrome, but we should not assume that.

I don't know that we have an appropriate macro to use in these tests, but we should figure something out.

Note that these tests don't actually do much in your configuration. See the TODO related to http://crbug.com/586634. It's possible that other efforts to improve registration will make this moot, but I'm not sure.

 Issue 468584  would hopefully give us the proper build flags for this. In the meantime, you could define a new preprocessor macro in the local GYP/GN file for this test.

There is some logic to build the stub CDM in third_party/widevine/cdm/BUILD.gn, but it is a bit scattered.

Thanks for the pointers.

Note that EncryptedMediaTest has a similar problem, e.g., MSE_Widevine/EncryptedMediaTest.Playback_AudioOnly_WebM/0 doesn't see the stub Widevine CDM anymore and fails.

The stub CDM is already built and available in this configuration (at out/Debug/WidevineCdm/_platform_specific/mac_x64/libwidevinecdm.dylib) when building browser_tests, and so is the adapter plugin.  It seems the plugin registration is the only missing part.  It used to be done manually via RegisterPepperCdm() in EncryptedMediaTest.  After 3be44be552846983cf371256718ce8ec81c565b4, is RegisterWidevineCdmComponent() supposed to succeed?  Can we make it successfully register the plugin and have it load the stub CDM when branding != Chrome?

Currently it looks for the plugin in "/Users/wdzierzanowski/src/chromium/src/out/Debug/Chromium.app/Contents/Versions/53.0.2774.0/Chromium Framework.framework/Libraries/WidevineCdm/_platform_specific/mac_x64/" and fails.  So we'd probably need a build step that copies the plugin files to this path.  We'd probably also need some fake plugin manifest for the registration to succeed.

If this is too cumbersome then perhaps we should just bring back RegisterPepperCdm() for the non-bundled Widevine case instead.

In any case, once we figure out some way to use the stub CDM in browset_tests again, can we use it in EncryptedMediaSupportedTypes tests too instead of changing the expectations to "Unsupported keySystem"?

I think the fundamental issue is that now we assume the CDM is actually available (shipped with the browser) if WIDEVINE_CDM_AVAILABLE is true. This is not the case for browsers that uses enable_widevine=1.

It's definitely possible to fake a manifest to get the test pass. With the manifest, DefaultComponentInstaller::FindPreinstallation() should find the CDM, and the CDM should will be registered there automatically. This will work on Windows GYP/GN builds, and Mac GYP build.

The only exception is Mac GN build, where the browser_tests uses SetOverrideAmIBundled(). So it'll look for the plugin in the bundled path directly, something like Chromium.app/Contents/Versions/53.0.2774.0/Chromium Framework.framework/Libraries/WidevineCdm/_platform_specific/mac_x64/. In this case, you'll need to make sure the cdm, adapter and manifest are in the bundled path  (currently we only do this for chrome branding), see 
https://chromiumcodereview.appspot.com/2033923002/ and the associated bug for details.

If you do this, you'll have to make sure you don't ship the manifest by accident in your production. I assume you are already doing this for the stub CDM somehow.

If that seems too much trouble. I am fine with just bringing back RegisterPepperCdm() as you suggested.

In either case, how we register the CDM is different from how the CDM is registered in production (where CDM is component updated), so we'll always have some gap in test coverage there.  But thinking about it more, by faking a bundled CDM we are actually closer to the production code since the CDM will be registered by component installer, which is what you use in production. Could you please give it a try to see how bad/hard it is?

give to xhwang@ so remove this bug from untriaged bucket.

I don't have time to work on this any time soon, so tentatively assign to wdzierzanowski. Feel free to reassign or remove yourself if you don't have time to work on this either.

Not right now, sorry.  I may have time to have a go at it in a few weeks though.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/119e34c6ce824a2ecd21e0aa3bc401ae604110fa

commit 119e34c6ce824a2ecd21e0aa3bc401ae604110fa
Author: wdzierzanowski <wdzierzanowski@opera.com>
Date: Fri Aug 26 14:33:13 2016

Bundle fake Widevine component manifest for stub CDM

Encrypted media browser tests involving Widevine use the stub CDM when
branding != Chrome.  This change allows them to register the
preinstalled component containing the stub CDM.

BUG= 622273 

TEST=Widevine browser tests 'browser_tests --gtest_filter=*Widevine*' pass

Review-Url: https://codereview.chromium.org/2136983002
Cr-Commit-Position: refs/heads/master@{#414706}

[modify] https://crrev.com/119e34c6ce824a2ecd21e0aa3bc401ae604110fa/chrome/BUILD.gn
[modify] https://crrev.com/119e34c6ce824a2ecd21e0aa3bc401ae604110fa/third_party/widevine/cdm/BUILD.gn
[add] https://crrev.com/119e34c6ce824a2ecd21e0aa3bc401ae604110fa/third_party/widevine/cdm/stub/manifest.json