ABANDONED: OOPIFs: Moving stitching of local paths from renderer to browser process.

content/public/renderer/render_frame.h

 // Copyright 2013 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 CONTENT_PUBLIC_RENDERER_RENDER_FRAME_H_
 #define CONTENT_PUBLIC_RENDERER_RENDER_FRAME_H_
 
 #include "base/callback_forward.h"
 #include "base/memory/scoped_ptr.h"
 #include "base/strings/string16.h"
@@ skipping 39 matching lines @@
 struct WebPluginInfo;
 struct WebPreferences;
 
 // This interface wraps functionality, which is specific to frames, such as
 // navigation. It provides communication with a corresponding RenderFrameHost
 // in the browser process.
 class CONTENT_EXPORT RenderFrame : public IPC::Listener,
                                    public IPC::Sender {
  public:
   // Returns the RenderFrame given a WebFrame.
+  static const RenderFrame* FromWebFrame(const blink::WebFrame* web_frame);

[ncarter (slow), 2015/10/08 20:57:55]

I appreciate the justification you gave for adding these const overrides in the
CL description, but for reasons I'll explain below, we shouldn't need them. The
TL;DR is that "const RenderFrame*" ought to be useless.

The rules we try to enforce for the content api (which this, being
content/public, is part of) are posted here:
http://www.chromium.org/developers/content-module/content-api. One of them says:
"Don't add the const identifier to interfaces. ... For interfaces implemented by
content, the implementation details doesn't have to be exposed."  Per that
policy, all the methods of RenderFrame ought to be non-const, and it's common
for RenderFrame's const-hostility to spilling over to code that has to interacts
with it. Although there are a couple const methods today, they're in violation
of the policy and we'd like to eradicate them too.

Yes, this goes against the Effective C++ recommendation of "use const wherever
possible", but doing so is a conscious decision.

As an alternative, I think we can either make the existing FromWebFrame method
accept a const WebFrame and return a non-const RenderFrame (using the const_cast
code you already added), or else just make the callers provide a non-const
WebFrame. 

[Łukasz Anforowicz, 2015/10/09 16:54:08]

Done:

- Removed const-related changes

- Added a GetRoutingIdForFrameOrProxy overload that takes
  a const WebFrame* (with a comment stating why const_cast
  there is safe).

   static RenderFrame* FromWebFrame(blink::WebFrame* web_frame);
 
   // Returns the RenderFrame given a routing id.
   static RenderFrame* FromRoutingID(int routing_id);
 
   // Returns the RenderView associated with this frame.
   virtual RenderView* GetRenderView() = 0;
 
   // Get the routing ID of the frame.
-  virtual int GetRoutingID() = 0;
+  virtual int GetRoutingID() const = 0;

[ncarter (slow), 2015/10/08 20:57:55]

Per the above, const methods in the content/public interfaces are forbidden.

[Łukasz Anforowicz, 2015/10/09 16:54:08]

Done.

 
   // Returns the associated WebFrame.
   virtual blink::WebLocalFrame* GetWebFrame() = 0;
 
   // Gets the focused element. If no such element exists then
   // the element will be Null.
   virtual blink::WebElement GetFocusedElement() const = 0;
 
    // Gets WebKit related preferences associated with this frame.
   virtual WebPreferences& GetWebkitPreferences() = 0;
@@ skipping 83 matching lines @@
 
  private:
   // This interface should only be implemented inside content.
   friend class RenderFrameImpl;
   RenderFrame() {}
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_RENDERER_RENDER_FRAME_H_