Oilpan: Enable Oilpan by default in modules/encryptedmedia

Source/bindings/templates/interface.h

Index: Source/bindings/templates/interface.h
diff --git a/Source/bindings/templates/interface.h b/Source/bindings/templates/interface.h
index 5eeb90f67d86725dfed778d53324c2348611bf15..8440e13744e8d45d8d47d73fd035bbaf0c59a14c 100644
--- a/Source/bindings/templates/interface.h
+++ b/Source/bindings/templates/interface.h
@@ -254,7 +254,6 @@ inline void v8SetReturnValueFast(const CallbackInfo& callbackInfo, {{cpp_class}}
 }
 {% endif %}{# has_custom_to_v8 #}
 
-{% if gc_type != 'GarbageCollectedObject' %}

[haraken, 2014/04/25 09:47:32]

It took me a long time to notice that I need to remove this line... If we have
the if branch, several encryptedmedia tests fail with strange errors.

Details:

- If we don't have the if branch, both toV8(MediaKeySession*) and
toV8(RawPtr<MediaKeySession>) are generated. If we have the if branch, only
toV8(MediaKeySession*) is generated.

- MediaKeySession is on-heap, so this CL replaces all RawPtr<MediaKeySession>
with MediaKeySession*, but the generated binding still uses
RawPtr<MediaKeySession> as follows:

  RawPtr<MediaKeySession> result = impl->create(...);
  return toV8(result.release());

The problem is that result.release() returns RawPtr<MediaKeySession> and that
MediaKeySession inherits from EventTarget which is still off-heap.

- As a result, toV8(result.release()) is bound to toV8(RawPtr<EventTarget>)
instead of toV8(MediaKeySession*). Then we end up returning a unexpected wrapper
to JS side.

I think there are two solutions to address this issue:

(a) Generate both toV8(RawPtr<X>) and toV8(X*) even if X is on-heap by default.

(b) Completely remove RawPtr<X> from the generated binding.


I think (a) is better for the following reasons:

- (b) will introduce a mess to the IDL compiler.

- Even if we completely remove RawPtr<X> from the generated binding, it's
possible that someone uses RawPtr<X> instead of X* in the code base. It won't
cause any compile issue and leads to the bug described above. To avoid this kind
of errors, it would be better to support both toV8(RawPtr<X>) and toV8(X*) for
safety.

Therefore this CL takes the approach (a).

[Mads Ager (chromium), 2014/04/28 11:02:31]

I think this is OK for now. How much would (b) complicate the code generator. We
should move away from using RawPtr as much as possible when going to the actual
types...

 inline v8::Handle<v8::Value> toV8({{pass_cpp_type}} impl, v8::Handle<v8::Object> creationContext, v8::Isolate* isolate)
 {
     return toV8(impl.get(), creationContext, isolate);
@@ -277,7 +276,6 @@ inline void v8SetReturnValueFast(const CallbackInfo& callbackInfo, {{pass_cpp_ty
 {
     v8SetReturnValueFast(callbackInfo, impl.get(), wrappable);
 }
-{% endif %}{# if gc_type != 'GarbageCollectedObject' #}
 
 {% if has_event_constructor %}
 bool initialize{{cpp_class}}({{cpp_class}}Init&, const Dictionary&, ExceptionState&, const v8::FunctionCallbackInfo<v8::Value>& info, const String& = "");