Removes MediaDecoderJob virtual method call from destructor.

Removes MediaDecoderJob virtual method call from destructor.

This execution path is currently seen used when destroying a
VideoDecoderJob that's still decoding:
* MediaDecoderJob::Release (early return, destroy_pending_=true)
* ...
* MediaDecoderJob::OnDecodeComplete
* ~VideoDecoderJob
* ~MediaDecoderJob
* MediaDecoderJob::ReleaseMediaCodecBridge
* MediaDecoderJob::OnMediaCodecBridgeReleased <-- !!!

The last line should be:
* VideoDecoderJob::OnMediaCodecBridgeReleased

but since it is invoked during the destructor the overridden
implementation is not executed.

R=qinmin@chromium.org,xhwang@chromium.org
BUG=internal b/17671489

Committed: https://crrev.com/6a1f7b511cdcb590bcebb8371e880908fe592a22
Cr-Commit-Position: refs/heads/master@{#299159}

[gunsch, 2014-10-10 00:27:35]

On 2014/10/09 20:41:49, gunsch wrote:

xhwang@ just pointed out that this CL is silly @trunk given
https://codereview.chromium.org/534063002. No need to review for now, will
re-apply that locally and then adapt this patch.

[gunsch, 2014-10-10 16:06:27]

gunsch@chromium.org changed reviewers:
+ ycheo@chromium.org

[gunsch, 2014-10-10 16:18:31]

Reopened, +ycheo.

Yuncheol pointed out that we should merge this to M37/M38 for android_webview.

I could use some pointers for Chromium release branch process. I saw the docs on
"working with release branches" but it sounds like the preferred approach is
"fix upstream and then cherry-pick to release branch" and not "submit CLs
straight to the release branch".

Since this patch doesn't currently fix anything upstream (see crbug/422158),
what is the recommended approach?

[qinmin, 2014-10-10 18:04:36]

On 2014/10/10 16:18:31, gunsch wrote:
> Reopened, +ycheo.
> 
> Yuncheol pointed out that we should merge this to M37/M38 for android_webview.
> 
> I could use some pointers for Chromium release branch process. I saw the docs
on
> "working with release branches" but it sounds like the preferred approach is
> "fix upstream and then cherry-pick to release branch" and not "submit CLs
> straight to the release branch".
> 
> Since this patch doesn't currently fix anything upstream (see crbug/422158),
> what is the recommended approach?

Ok, we can submit it on trunk first, and then after webview patches it, we
revert the CL

lgtm for now

[gunsch, 2014-10-10 18:25:58]

The CQ bit was checked by gunsch@chromium.org

[commit-bot: I haz the power, 2014-10-10 18:26:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/647553003/1

[gunsch, 2014-10-10 18:33:15]

Alright, I'll push this in for now.

Yuncheol, what's the process for cherry-picking for android_webview? This is not
easily testable using content shell or even Clank. Do you want to drive that?

[commit-bot: I haz the power, 2014-10-10 19:21:35]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-10-10 19:22:25]

Patchset 1 (id:??) landed as
https://crrev.com/6a1f7b511cdcb590bcebb8371e880908fe592a22
Cr-Commit-Position: refs/heads/master@{#299159}

[ycheo (away), 2014-10-11 00:33:58]

On 2014/10/10 18:33:15, gunsch wrote:
> Alright, I'll push this in for now.
> 
> Yuncheol, what's the process for cherry-picking for android_webview? This is
not
> easily testable using content shell or even Clank. Do you want to drive that?

Thanks for handling this.
Just cherry-picking to m37/m38 branch will apply to android_webview also.
I'll take the cherry-picking.