[NotLanded] Implement the fetching algorithm of the Web Manifest.

Source/core/loader/ManifestLoader.h

Index: Source/core/loader/ManifestLoader.h
diff --git a/Source/core/loader/ManifestLoader.h b/Source/core/loader/ManifestLoader.h
new file mode 100644
index 0000000000000000000000000000000000000000..e9d725852069d1b76f9d8fb505d2d1189214bd77
--- /dev/null
+++ b/Source/core/loader/ManifestLoader.h
@@ -0,0 +1,44 @@
+// Copyright 2014 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.
+
+#ifndef ManifestLoader_h
+#define ManifestLoader_h
+
+#include "core/fetch/ResourceClient.h"
+#include "core/fetch/ResourceOwner.h"
+#include "core/frame/LocalFrame.h"
+
+namespace blink {
+
+class Document;
+
+// The ManifestLoader is a class that fetches and parses a WebManifest and
+// informs the passed ManifestLoaderClient upon completion (success or failure).
+// The lifetime of the object is managed by itself. When ::LoadManifest() is
+// called an instance of the object is created and as soon as the processing
+// is finished, the object will destroy itself.
+// The call should make sure that the ManifestLoaderClient passed to
+// ::LoadManifest() is not destroyed before getting a result.
+class ManifestLoader FINAL : public ResourceOwner<Resource, ResourceClient> {
+public:
+    static void loadManifest(PassRefPtr<LocalFrame>);
+
+    // This is public so we can use OwnPtr<>(this) in various methods.
+    virtual ~ManifestLoader();
+
+protected:
+    // ResourceClient
+    virtual void notifyFinished(Resource*) OVERRIDE;
+
+    explicit ManifestLoader(PassRefPtr<LocalFrame>);
+
+    void startLoading();
+
+private:
+    RefPtr<LocalFrame> m_frame;

[Nate Chapin, 2014/08/25 20:43:12]

Should ManifestLoader be able to keep the frame alive, or should it abort if the
frame is being destroyed?

My gut reaction is that ManifestLoader should inherit from
FrameDestructionObserver and cancel the load on frame detach, but I'm willing to
be persuaded otherwise.

[mlamouri (slow - plz ping), 2014/08/26 17:25:23]

I tend to prefer to keep the frame alive but as you, I could be convinced
otherwise. With the short term plans regarding how we are going to use the
manifest, it will have no impact: we will only request it when the user will try
to add the tab to homescreen so we shouldn't expect the frame to go away.
Though, if it had to happen, we would want the request to finish so we can
proceed with the user's request.

In future plans, we might want to download the manifest in the background even
without a tab being open. We can't do that now given that we need a frame in
order to do the fetching.

+};
+
+} // namespace blink
+
+#endif