ResourceFetcherTest: introduce FetchTestingPlatformSupport

third_party/WebKit/Source/core/fetch/MockFetchContext.h

Index: third_party/WebKit/Source/core/fetch/MockFetchContext.h
diff --git a/third_party/WebKit/Source/core/fetch/MockFetchContext.h b/third_party/WebKit/Source/core/fetch/MockFetchContext.h
index 01e52d09c56ea6ad670f9aa6ccaa1a3390088bf8..e7dc39f6df5081c76354bd0abff0c31f8534b5a6 100644
--- a/third_party/WebKit/Source/core/fetch/MockFetchContext.h
+++ b/third_party/WebKit/Source/core/fetch/MockFetchContext.h
@@ -35,6 +35,12 @@ class MockFetchContext : public FetchContext {
 
   ~MockFetchContext() override {}
 
+  void setCachePolicy(CachePolicy policy) { m_policy = policy; }
+  void setLoadComplete(bool complete) { m_complete = complete; }
+  long long getTransferSize() const { return m_transferSize; }
+  void runLoadingTaskRunnerUntilIdle() { m_runner->runUntilIdle(); }
+
+  // FetchContext:
   bool allowImage(bool imagesEnabled, const KURL&) const override {
     return true;
   }
@@ -51,17 +57,12 @@ class MockFetchContext : public FetchContext {
     return m_loadPolicy == kShouldLoadNewResource;
   }
   RefPtr<WebTaskRunner> loadingTaskRunner() const override { return m_runner; }

[kinuko, 2017/01/19 18:40:18]

Could you help me understand... so the task runner returned by this fetch
context and the task runner that is returned by
Platform::current()->currentThread()->scheduler()->loadingTaskRunner() are
different, is that right?  Wouldn't that become a problem at some point?

[Takashi Toyoshima, 2017/01/20 04:13:16]

The right approach to obtain the task runner in fetch is to access it via
FetchContext since it's per-frame runner. But unfortunately as you noticed, we
are using currentThread()->scheduler()->loadingTaskRunner() in some modules,
e.g. MemoryCache, Resource, and RawResource. Probably, we could change to use
per-frame task runner for *Resource, but I have no idea about the MemoryCache.
Probably, we will continue to use per-frame runner.

Once we move this test to platform, currentThread()->scheduler() is mocked by
TestingPlatformSupportWithMockScheduler. That does not have a MessageLoop, and
need to call another runUntilIdle method that the testing Platform instance has.
So anyway, current WebURLLoaderMockFactory's RunLoop does not work.

If all MockFetchContext users are moved to platform, we could change this to
return a task runner mocked by TestingPlatform..., but since this is used by
core/loader tests, using FakeWebTaskRunner here is a point of compromise.

[kinuko, 2017/01/20 05:00:33]

When you say MemoryCache do you mean the task observers for pruning?  And I see
it comes from the browser... I feel we might be able to deprecate the Web Cache
manager and this prune code path as we now have memory coordinator, but that's
probably another story.
Yep I noticed it.
 
Do you mean you're assuming we can't use TestingPlatform if the test's not in
platform?

-
-  void setCachePolicy(CachePolicy policy) { m_policy = policy; }
   CachePolicy getCachePolicy() const override { return m_policy; }
-  void setLoadComplete(bool complete) { m_complete = complete; }
   bool isLoadComplete() const override { return m_complete; }
-
   void addResourceTiming(
       const ResourceTimingInfo& resourceTimingInfo) override {
     m_transferSize = resourceTimingInfo.transferSize();
   }
-  long long getTransferSize() const { return m_transferSize; }
 
  private:
   MockFetchContext(LoadPolicy loadPolicy)