Removed FrameView's windowToContents and contentsToWindow methods.

Source/core/frame/FrameView.h

Index: Source/core/frame/FrameView.h
diff --git a/Source/core/frame/FrameView.h b/Source/core/frame/FrameView.h
index e17893b2d44f73bce4eb4d9826adfb86e757c15c..769f4cdad8378cb1922b11b76b71a6458dc12214 100644
--- a/Source/core/frame/FrameView.h
+++ b/Source/core/frame/FrameView.h
@@ -473,18 +473,21 @@ public:
     bool drawPanScrollIcon() { return m_shouldDrawPanScrollIcon; }
 
     IntPoint rootFrameToContents(const IntPoint&) const;

[Rick Byers, 2015/03/05 17:56:20]

Can you add a brief description of each of the co-ordinate system terms here?
e.g. make it clear that only viewport co-ordinates take pinch-zoom into account.

[bokan, 2015/03/06 21:54:37]

Done.

+    FloatPoint rootFrameToContents(const FloatPoint&) const;
     IntRect rootFrameToContents(const IntRect&) const;
     IntPoint contentsToRootFrame(const IntPoint&) const;
     IntRect contentsToRootFrame(const IntRect&) const;
 
-    // Event coordinates are assumed to be in the coordinate space of a window that contains
-    // the entire widget hierarchy. It is up to the platform to decide what the precise definition
-    // of containing window is. (For example on Mac it is the containing NSWindow.)

[Rick Byers, 2015/03/05 17:56:20]

Does any of this comment still apply?  Eg. your CL description claims that
Window is equivalent to RootFrame, but this comment suggests that's not
necessarily the case on all platforms (eg. does the platform window ever add
some padding?).

[bokan, 2015/03/06 21:54:37]

I don't think so, I think this comment is out of date and there seems to be no
platform specificity here anymore. That said, I came to that conclusion through
grepping code so I'll look more closely at how this code runs on other
platforms.

[Rick Byers, 2015/03/07 15:44:08]

Nice, that would be an improvement if it's true (as I also suspect it is - I was
surprised to see this comment, I thought window was always root frame).  If this
comment dates back to WebKit then "platform" obviously had a much larger
meaning.  

-    IntPoint windowToContents(const IntPoint&) const;
-    FloatPoint windowToContents(const FloatPoint&) const;
-    IntPoint contentsToWindow(const IntPoint&) const;
-    IntRect windowToContents(const IntRect&) const;
-    IntRect contentsToWindow(const IntRect&) const;
+    IntRect viewportToContents(const IntRect&) const;
+    IntRect contentsToViewport(const IntRect&) const;
+    IntPoint contentsToViewport(const IntPoint&) const;
+    IntPoint viewportToContents(const IntPoint&) const;
+
+    // FIXME: Some external callers expect to get back a rect that's positioned
+    // in viewport space, but sized in CSS pixels. This is an artefact of the

[Rick Byers, 2015/03/05 17:56:20]

nit: artifact

[bokan, 2015/03/06 21:54:37]

Done. (Though either works:
http://english.stackexchange.com/questions/37903/difference-between-artifact-...)
:)

[Rick Byers, 2015/03/07 15:44:08]

Oh sorry!  I thought this was just a typo - I'm not one to insist on American
spelling :-)

+    // old pinch-zoom path. These callers should be converted to expect a rect
+    // fully in viewport space. crbug.com/459591.
+    IntRect soonToBeRemovedContentsToUnscaledViewport(const IntRect&) const;
 
     // Methods for converting between Frame and Content (i.e. Document) coordinates.
     // Frame coordinates are relative to the top left corner of the frame and so