Oilpan: Ship Oilpan for serviceworkers/

Oilpan: Ship Oilpan for serviceworkers/

BUG=340522
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=181429

[haraken, 2014-08-18 16:03:26]

This is still work-in-progress. Not yet for review.

https://codereview.chromium.org/478693005/diff/20001/Source/platform/exported...
File Source/platform/exported/WebServiceWorkerRegistrationProxy.cpp (right):

https://codereview.chromium.org/478693005/diff/20001/Source/platform/exported...
Source/platform/exported/WebServiceWorkerRegistrationProxy.cpp:8: #include
"modules/serviceworkers/ServiceWorkerRegistration.h"

This violates #include dependency rules. I think we need to move
ServiceWorkerRegistration to platform/serviceworkers/.

[haraken, 2014-08-25 06:15:16]

nhiroki, dominicc@: Added
platform/serviceworkers/ServiceWorkerRegistrationProxy.h. Would you take a look
at the following files?

- ServiceWorkerRegistrationProxy.h
- ServiceWorkerRegistration.cpp
- WebServiceWorkerRegistrationProxy.{h,cpp}

If the approach look fine, I'll clean up the CL a bit more and upload it for
full review.

[haraken, 2014-08-26 01:14:32]

nhiroki@, dominicc@: friendly ping :)

[dominicc (has gone to gerrit), 2014-08-26 14:01:34]

LGTM.

The #includes for GarbageCollected, Member, etc. seem a little loose; what's the
guideline for Oilpan types? Would seem to relax include-what-you-use quite a
bit.

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/CacheStorage.cpp (right):

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/CacheStorage.cpp:104: CacheStorage*
CacheStorage::create(WebServiceWorkerCacheStorage* webCacheStorage)
Now that this is a simple "new" can we remove this helper method?

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/FetchEvent.h (right):

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/FetchEvent.h:43: PersistentWillBeMember<Request>
m_request;
Should we IWYU here?

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/ServiceWorkerClient.cpp (right):

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/ServiceWorkerClient.cpp:16: ServiceWorkerClient*
ServiceWorkerClient::create(unsigned id)
Same with this one.

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/ServiceWorkerClients.cpp (right):

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/ServiceWorkerClients.cpp:45: ServiceWorkerClients*
ServiceWorkerClients::create()
Ditto.

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/ServiceWorkerContainer.h (right):

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/ServiceWorkerContainer.h:91:
RefPtrWillBeMember<ServiceWorker> m_active;
Just out of curiosity, what is blocking doing this one too?

[nhiroki, 2014-08-28 09:09:25]

On 2014/08/25 06:15:16, haraken wrote:
> nhiroki, dominicc@: Added
> platform/serviceworkers/ServiceWorkerRegistrationProxy.h. Would you take a
look
> at the following files?
> 
> - ServiceWorkerRegistrationProxy.h
> - ServiceWorkerRegistration.cpp
> - WebServiceWorkerRegistrationProxy.{h,cpp}
> 
> If the approach look fine, I'll clean up the CL a bit more and upload it for
> full review.

LGTM (sorry for my delayed reply)

[haraken, 2014-08-28 09:12:37]

On 2014/08/28 09:09:25, nhiroki wrote:
> On 2014/08/25 06:15:16, haraken wrote:
> > nhiroki, dominicc@: Added
> > platform/serviceworkers/ServiceWorkerRegistrationProxy.h. Would you take a
> look
> > at the following files?
> > 
> > - ServiceWorkerRegistrationProxy.h
> > - ServiceWorkerRegistration.cpp
> > - WebServiceWorkerRegistrationProxy.{h,cpp}
> > 
> > If the approach look fine, I'll clean up the CL a bit more and upload it for
> > full review.
> 
> LGTM (sorry for my delayed reply)

Thanks!

However, I noticed that I need to move WaitUntilObserver and RespondWithObserver
to oilpan's heap before shipping Oipan for serviceworkers/. And in order to move
them to oilpan's heap, I need to rewrite the lifetime management of
ScriptFunction. I'll finish the work first and get back to this CL. Let me ping
you once it's ready :)

[haraken, 2014-09-03 07:49:10]

> The #includes for GarbageCollected, Member, etc. seem a little loose; what's
the
> guideline for Oilpan types? Would seem to relax include-what-you-use quite a
> bit.

The rule for Handle.h is include-so-that-it-compiles, just like v8.h.

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/CacheStorage.cpp (right):

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/CacheStorage.cpp:104: CacheStorage*
CacheStorage::create(WebServiceWorkerCacheStorage* webCacheStorage)
On 2014/08/26 14:01:34, dominicc--slow until 9.9 wrote:
> Now that this is a simple "new" can we remove this helper method?

As far as I know, Blink prefers having a create method in general even if it's
simple. So let me keep that.

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/FetchEvent.h (right):

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/FetchEvent.h:43: PersistentWillBeMember<Request>
m_request;
On 2014/08/26 14:01:34, dominicc--slow until 9.9 wrote:
> Should we IWYU here?

Done.

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
File Source/modules/serviceworkers/ServiceWorkerContainer.h (right):

https://codereview.chromium.org/478693005/diff/40001/Source/modules/servicewo...
Source/modules/serviceworkers/ServiceWorkerContainer.h:91:
RefPtrWillBeMember<ServiceWorker> m_active;
On 2014/08/26 14:01:34, dominicc--slow until 9.9 wrote:
> Just out of curiosity, what is blocking doing this one too?

ServiceWorker inherits from AbstractWorker and we've not yet shipped oilpan for
AbstractWorker. I'll try it in a follow-up CL.

[haraken, 2014-09-03 07:50:19]

I think the CL is now ready for full review. It passes all tests in both oilpan
and non-oilpan tests without any leaks.

It looks like serviceworker people are happy with the change, so would any
oilpan reviewer take a final look?

[Mads Ager (chromium), 2014-09-03 08:17:33]

ager@chromium.org changed reviewers:
+ ager@chromium.org

[Mads Ager (chromium), 2014-09-03 08:17:34]

https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
File Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h (right):

https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h:38:
ServiceWorkerRegistration* m_registration;
If we are not tracing this pointer I don't understand why we have the
ServiceWorkerRegistrationProxy? It seems to me that this just means that
WebServiceWorkerRegistration does not keep the ServiceWorkerRegistration alive
and that sounds dangerous?

Does it lead to a Persistent/RefPtr cycle if we have a
WebPrivatePtr<ServiceWorkerRegistration> in WebServiceWorkerRegistration?

Am I right that we currently have:

WebSWRegistration --- Persistent -->
SWRegistrationProxy --- Raw -->
SWRegistration?

That would mean that if someone holds on to a WebSWRegistration that will not
actually keep the registration alive? Am I missing something?

[haraken, 2014-09-03 08:26:53]

Thanks for review.

https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
File Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h (right):

https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h:38:
ServiceWorkerRegistration* m_registration;
On 2014/09/03 08:17:34, Mads Ager (chromium) wrote:
> If we are not tracing this pointer I don't understand why we have the
> ServiceWorkerRegistrationProxy? It seems to me that this just means that
> WebServiceWorkerRegistration does not keep the ServiceWorkerRegistration alive
> and that sounds dangerous?
> 
> Does it lead to a Persistent/RefPtr cycle if we have a
> WebPrivatePtr<ServiceWorkerRegistration> in WebServiceWorkerRegistration?
> 
> Am I right that we currently have:
> 
> WebSWRegistration --- Persistent -->
> SWRegistrationProxy --- Raw -->
> SWRegistration?
> 
> That would mean that if someone holds on to a WebSWRegistration that will not
> actually keep the registration alive? Am I missing something?

The relationship is as follows:

WebSWRegistrationProxy --- Persistent -->
SWRegistrationProxy --- Raw -->
SWRegistration

and the SWRegistration and the WebSWRegistrationProxy are the same object
(SWRegistration inherits from WebSWRegistrationProxy).

Thus we _should_not_ trace the SWRegistration from SWRegistrationProxy. If we
trace it, it will produce a leak.

[Mads Ager (chromium), 2014-09-03 08:40:40]

On 2014/09/03 08:26:53, haraken wrote:
> Thanks for review.
> 
>
https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
> File Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h (right):
> 
>
https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
> Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h:38:
> ServiceWorkerRegistration* m_registration;
> On 2014/09/03 08:17:34, Mads Ager (chromium) wrote:
> > If we are not tracing this pointer I don't understand why we have the
> > ServiceWorkerRegistrationProxy? It seems to me that this just means that
> > WebServiceWorkerRegistration does not keep the ServiceWorkerRegistration
alive
> > and that sounds dangerous?
> > 
> > Does it lead to a Persistent/RefPtr cycle if we have a
> > WebPrivatePtr<ServiceWorkerRegistration> in WebServiceWorkerRegistration?
> > 
> > Am I right that we currently have:
> > 
> > WebSWRegistration --- Persistent -->
> > SWRegistrationProxy --- Raw -->
> > SWRegistration?
> > 
> > That would mean that if someone holds on to a WebSWRegistration that will
not
> > actually keep the registration alive? Am I missing something?
> 
> The relationship is as follows:
> 
> WebSWRegistrationProxy --- Persistent -->
> SWRegistrationProxy --- Raw -->
> SWRegistration
> 
> and the SWRegistration and the WebSWRegistrationProxy are the same object
> (SWRegistration inherits from WebSWRegistrationProxy).
> 
> Thus we _should_not_ trace the SWRegistration from SWRegistrationProxy. If we
> trace it, it will produce a leak.

OK, so the WebSWRegistrationProxy is just a limited interface on the
SWRegistration. In that case can we remove the SWRegistrationProxy from the
chain again?

WebSWRegistrationProxy --- Raw -->
SWRegistration

The we can have a comment in WebSWRegistrationProxy that the raw pointer is safe
because it is a pointer to this object itself?

Would that work or does the SWRegistrationProxy class serve some other purpose?

[haraken, 2014-09-03 08:46:04]

On 2014/09/03 08:40:40, Mads Ager (chromium) wrote:
> On 2014/09/03 08:26:53, haraken wrote:
> > Thanks for review.
> > 
> >
>
https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
> > File Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h
(right):
> > 
> >
>
https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
> > Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h:38:
> > ServiceWorkerRegistration* m_registration;
> > On 2014/09/03 08:17:34, Mads Ager (chromium) wrote:
> > > If we are not tracing this pointer I don't understand why we have the
> > > ServiceWorkerRegistrationProxy? It seems to me that this just means that
> > > WebServiceWorkerRegistration does not keep the ServiceWorkerRegistration
> alive
> > > and that sounds dangerous?
> > > 
> > > Does it lead to a Persistent/RefPtr cycle if we have a
> > > WebPrivatePtr<ServiceWorkerRegistration> in WebServiceWorkerRegistration?
> > > 
> > > Am I right that we currently have:
> > > 
> > > WebSWRegistration --- Persistent -->
> > > SWRegistrationProxy --- Raw -->
> > > SWRegistration?
> > > 
> > > That would mean that if someone holds on to a WebSWRegistration that will
> not
> > > actually keep the registration alive? Am I missing something?
> > 
> > The relationship is as follows:
> > 
> > WebSWRegistrationProxy --- Persistent -->
> > SWRegistrationProxy --- Raw -->
> > SWRegistration
> > 
> > and the SWRegistration and the WebSWRegistrationProxy are the same object
> > (SWRegistration inherits from WebSWRegistrationProxy).
> > 
> > Thus we _should_not_ trace the SWRegistration from SWRegistrationProxy. If
we
> > trace it, it will produce a leak.
> 
> OK, so the WebSWRegistrationProxy is just a limited interface on the
> SWRegistration. In that case can we remove the SWRegistrationProxy from the
> chain again?
> 
> WebSWRegistrationProxy --- Raw -->
> SWRegistration
> 
> The we can have a comment in WebSWRegistrationProxy that the raw pointer is
safe
> because it is a pointer to this object itself?

Ah, this is a good idea. Let me try.

[haraken, 2014-09-03 12:27:54]

On 2014/09/03 08:40:40, Mads Ager (chromium) wrote:
> On 2014/09/03 08:26:53, haraken wrote:
> > Thanks for review.
> > 
> >
>
https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
> > File Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h
(right):
> > 
> >
>
https://codereview.chromium.org/478693005/diff/80001/Source/platform/servicew...
> > Source/platform/serviceworkers/ServiceWorkerRegistrationProxy.h:38:
> > ServiceWorkerRegistration* m_registration;
> > On 2014/09/03 08:17:34, Mads Ager (chromium) wrote:
> > > If we are not tracing this pointer I don't understand why we have the
> > > ServiceWorkerRegistrationProxy? It seems to me that this just means that
> > > WebServiceWorkerRegistration does not keep the ServiceWorkerRegistration
> alive
> > > and that sounds dangerous?
> > > 
> > > Does it lead to a Persistent/RefPtr cycle if we have a
> > > WebPrivatePtr<ServiceWorkerRegistration> in WebServiceWorkerRegistration?
> > > 
> > > Am I right that we currently have:
> > > 
> > > WebSWRegistration --- Persistent -->
> > > SWRegistrationProxy --- Raw -->
> > > SWRegistration?
> > > 
> > > That would mean that if someone holds on to a WebSWRegistration that will
> not
> > > actually keep the registration alive? Am I missing something?
> > 
> > The relationship is as follows:
> > 
> > WebSWRegistrationProxy --- Persistent -->
> > SWRegistrationProxy --- Raw -->
> > SWRegistration
> > 
> > and the SWRegistration and the WebSWRegistrationProxy are the same object
> > (SWRegistration inherits from WebSWRegistrationProxy).
> > 
> > Thus we _should_not_ trace the SWRegistration from SWRegistrationProxy. If
we
> > trace it, it will produce a leak.
> 
> OK, so the WebSWRegistrationProxy is just a limited interface on the
> SWRegistration. In that case can we remove the SWRegistrationProxy from the
> chain again?
> 
> WebSWRegistrationProxy --- Raw -->
> SWRegistration
> 
> The we can have a comment in WebSWRegistrationProxy that the raw pointer is
safe
> because it is a pointer to this object itself?
> 
> Would that work or does the SWRegistrationProxy class serve some other
purpose?

Done. Would you take another look?

[Mads Ager (chromium), 2014-09-03 12:47:17]

LGTM

https://codereview.chromium.org/478693005/diff/100001/Source/platform/blink_p...
File Source/platform/blink_platform.gypi (right):

https://codereview.chromium.org/478693005/diff/100001/Source/platform/blink_p...
Source/platform/blink_platform.gypi:786:
'serviceworkers/ServiceWorkerRegistrationProxy.h',
Remove this line again?

[haraken, 2014-09-03 12:52:06]

https://codereview.chromium.org/478693005/diff/100001/Source/platform/blink_p...
File Source/platform/blink_platform.gypi (right):

https://codereview.chromium.org/478693005/diff/100001/Source/platform/blink_p...
Source/platform/blink_platform.gypi:786:
'serviceworkers/ServiceWorkerRegistrationProxy.h',
On 2014/09/03 12:47:17, Mads Ager (chromium) wrote:
> Remove this line again?

Done.

[haraken, 2014-09-03 12:52:17]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2014-09-03 12:52:59]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/haraken@chromium.org/478693005/120001

[commit-bot: I haz the power, 2014-09-03 13:58:33]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)

[commit-bot: I haz the power, 2014-09-03 14:02:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-03 14:02:27]

Try jobs failed on following builders:
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)

[haraken, 2014-09-03 14:40:18]

haraken@chromium.org changed reviewers:
+ tkent@chromium.org

[haraken, 2014-09-03 14:40:18]

+tkent-san: Would you take a look at web/ and public/?

[haraken, 2014-09-04 02:46:31]

haraken@chromium.org changed reviewers:
+ jochen@chromium.org

[haraken, 2014-09-04 02:46:32]

tkent-san is OOO.

jochen@: Would you take a look at web/ and public/?

[jochen (gone - plz use gerrit), 2014-09-04 09:26:09]

should there be some kind of announcement mail about this on blink-dev?

I know that service workers hasn't shipped yet, but are you sure that coupling
service workers and oilpan together is a good idea right now?

[haraken, 2014-09-04 09:31:13]

> should there be some kind of announcement mail about this on blink-dev?

I've announced that we started shipping oilpan for modules and Mads updated the
status two weeks ago. We haven't sent per-module announcement to blink-dev and
alternately have consulted with each module OWNER if it's OK or not.

> I know that service workers hasn't shipped yet, but are you sure that coupling
> service workers and oilpan together is a good idea right now?

I don't see any particular issue. dominicc and nhiroki (serviceworker experts)
are happy with it, as they LGed above.

[jochen (gone - plz use gerrit), 2014-09-04 09:41:40]

On 2014/09/04 at 09:31:13, haraken wrote:
> > should there be some kind of announcement mail about this on blink-dev?
> 
> I've announced that we started shipping oilpan for modules and Mads updated
the status two weeks ago. We haven't sent per-module announcement to blink-dev
and alternately have consulted with each module OWNER if it's OK or not.
> 

ah, ok, I missed that.

> > I know that service workers hasn't shipped yet, but are you sure that
coupling
> > service workers and oilpan together is a good idea right now?
> 
> I don't see any particular issue. dominicc and nhiroki (serviceworker experts)
are happy with it, as they LGed above.

well then, lgtm

[haraken, 2014-09-04 09:42:32]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2014-09-04 09:42:48]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/haraken@chromium.org/478693005/120001

[commit-bot: I haz the power, 2014-09-04 09:43:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-04 09:43:10]

Failed to apply patch for Source/modules/serviceworkers/Request.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file Source/modules/serviceworkers/Request.h
  Hunk #2 FAILED at 23.
  1 out of 3 hunks FAILED -- saving rejects to file
Source/modules/serviceworkers/Request.h.rej

Patch:       Source/modules/serviceworkers/Request.h
Index: Source/modules/serviceworkers/Request.h
diff --git a/Source/modules/serviceworkers/Request.h
b/Source/modules/serviceworkers/Request.h
index
88d390ae0943a339bb103af98c8e0cf36cf7e820..766aa0e5991bc3a60f4341adc14d5b096b77661f
100644
--- a/Source/modules/serviceworkers/Request.h
+++ b/Source/modules/serviceworkers/Request.h
@@ -12,7 +12,6 @@
 #include "modules/serviceworkers/Headers.h"
 #include "platform/heap/Handle.h"
 #include "platform/weborigin/KURL.h"
-#include "wtf/RefCounted.h"
 #include "wtf/RefPtr.h"
 #include "wtf/text/WTFString.h"
 
@@ -24,25 +23,24 @@ class ResourceRequest;
 struct ThreadableLoaderOptions;
 class WebServiceWorkerRequest;
 
-class Request FINAL : public RefCountedWillBeGarbageCollected<Request>, public
ScriptWrappable {
-    DECLARE_EMPTY_DESTRUCTOR_WILL_BE_REMOVED(Request);
+class Request FINAL : public GarbageCollected<Request>, public ScriptWrappable
{
     DEFINE_WRAPPERTYPEINFO();
 public:
-    static PassRefPtrWillBeRawPtr<Request> create(ExecutionContext*, const
String&, ExceptionState&);
-    static PassRefPtrWillBeRawPtr<Request> create(ExecutionContext*, const
String&, const Dictionary&, ExceptionState&);
-    static PassRefPtrWillBeRawPtr<Request> create(ExecutionContext*, Request*,
ExceptionState&);
-    static PassRefPtrWillBeRawPtr<Request> create(ExecutionContext*, Request*,
const Dictionary&, ExceptionState&);
+    static Request* create(ExecutionContext*, const String&, ExceptionState&);
+    static Request* create(ExecutionContext*, const String&, const Dictionary&,
ExceptionState&);
+    static Request* create(ExecutionContext*, Request*, ExceptionState&);
+    static Request* create(ExecutionContext*, Request*, const Dictionary&,
ExceptionState&);
 
-    static PassRefPtrWillBeRawPtr<Request>
create(PassRefPtrWillBeRawPtr<FetchRequestData>);
+    static Request* create(FetchRequestData*);
 
-    static PassRefPtrWillBeRawPtr<Request> create(const
WebServiceWorkerRequest&);
+    static Request* create(const WebServiceWorkerRequest&);
 
-    PassRefPtrWillBeRawPtr<FetchRequestData> request() { return m_request; }
+    FetchRequestData* request() { return m_request; }
 
     String method() const;
     String url() const;
-    PassRefPtrWillBeRawPtr<Headers> headers() const { return m_headers; }
-    PassRefPtrWillBeRawPtr<FetchBodyStream> body(ExecutionContext*);
+    Headers* headers() const { return m_headers; }
+    FetchBodyStream* body(ExecutionContext*);
     String referrer() const;
     String mode() const;
     String credentials() const;
@@ -52,12 +50,12 @@ public:
     void trace(Visitor*);
 
 private:
-    explicit Request(PassRefPtrWillBeRawPtr<FetchRequestData>);
+    explicit Request(FetchRequestData*);
     explicit Request(const WebServiceWorkerRequest&);
 
-    RefPtrWillBeMember<FetchRequestData> m_request;
-    RefPtrWillBeMember<Headers> m_headers;
-    RefPtrWillBeMember<FetchBodyStream> m_fetchBodyStream;
+    Member<FetchRequestData> m_request;
+    Member<Headers> m_headers;
+    Member<FetchBodyStream> m_fetchBodyStream;
 };
 
 } // namespace blink

[haraken, 2014-09-04 12:03:08]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2014-09-04 12:03:20]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/haraken@chromium.org/478693005/160001

[commit-bot: I haz the power, 2014-09-04 18:11:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-04 18:11:21]

Try jobs failed on following builders:
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/51591)

[haraken, 2014-09-04 23:30:58]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2014-09-04 23:31:47]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/haraken@chromium.org/478693005/160001

[commit-bot: I haz the power, 2014-09-04 23:39:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-04 23:39:02]

Try jobs failed on following builders:
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/51818)

[haraken, 2014-09-04 23:59:43]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2014-09-05 00:00:22]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/haraken@chromium.org/478693005/180001

[commit-bot: I haz the power, 2014-09-05 02:46:18]

Committed patchset #10 (id:180001) as 181429