Plumb render view ID from audio-related code in renderer through IPCs to AudioRendererHost in brows…

content/renderer/renderer_webkitplatformsupport_impl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/renderer_webkitplatformsupport_impl.h"
 
 #include "base/command_line.h"
 #include "base/file_path.h"
 #include "base/file_util.h"
 #include "base/metrics/histogram.h"
@@ skipping 592 matching lines @@
       layout = media::CHANNEL_LAYOUT_7_1;
       break;
     default:
       layout = media::CHANNEL_LAYOUT_STEREO;
   }
 
   media::AudioParameters params(
       media::AudioParameters::AUDIO_PCM_LOW_LATENCY, layout,
       static_cast<int>(sampleRate), 16, bufferSize);
 
-  return new RendererWebAudioDeviceImpl(params, callback);
+  // TODO(miu): This method should be moved to RenderViewImpl.  First, a WebKit
+  // change must land: https://bugs.webkit.org/show_bug.cgi?id=92718
+  // This issue is being tracked in http://crbug.com/156535.  For now, a stub:
+  static const int kUnknownRenderViewId = -1;
+  return new RendererWebAudioDeviceImpl(kUnknownRenderViewId, params, callback);

[jamesr, 2012/10/29 22:51:02]

I think this is not quite the right way to plumb this.  When you create an audio
device, it shouldn't really care about what render view ID it's associated with
- you really only care when you are going to play sound (i.e. the
WebAudioDevice::start() call).

I think the way to plumb this is to look at how web sockets work.  The lifecycle
there is something like this:
1.) WebKit creates a WebSocketStreamHandle via
Platform::createSocketStreamHandle().  The object is constructed on the chromium
side
2.) when WebKit's ready to use the socket, it calls
WebFrameClient::willOpenSocketStream(WebSocketStreamHandle*).  The chromium
implementation of this uses this call to associated the implementation of
WebSocketStreamHandle with the context of the WebFrame (which is associated with
a view, etc).
3.) WebKit uses the WebSocketStreamHandle to do whatever it likes and the
chromium side has the metadata associations it needs.

We really do not want to make WebKit directly aware of RenderViewIds.  It's not
a concern of WebKit how these things are hooked up and it doesn't impact the
operation of WebKit at all.  Instead, we should keep metadata associations like
this contained on the chromium side and use callbacks to associate state that we
need.

 }
 
 //------------------------------------------------------------------------------
 
 WebKit::WebString
 RendererWebKitPlatformSupportImpl::signedPublicKeyAndChallengeString(
     unsigned key_size_index,
     const WebKit::WebString& challenge,
     const WebKit::WebURL& url) {
   std::string signed_public_key;
@@ skipping 129 matching lines @@
     const char16* characters,
     size_t length,
     size_t before_index,
     const WebKit::WebString& locale) {
   // Crash if WebKit calls this function when canHyphenate returns false.
   DCHECK(locale.isEmpty() || locale.equals("en-US"));
   DCHECK(hyphenator_.get());
   return hyphenator_->ComputeLastHyphenLocation(string16(characters, length),
                                                 before_index);
 }