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..cff83f8d3862003a2541ec95d9b91bc496f75a19 100644
--- a/Source/core/frame/FrameView.h
+++ b/Source/core/frame/FrameView.h
@@ -472,19 +472,51 @@ public:
 
     bool drawPanScrollIcon() { return m_shouldDrawPanScrollIcon; }
 
+    // Coordinate space transform methods.

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

These comments are great, thanks!  Make sure to link to this in your blink-dev
PSA.

Can you also mention the impact of browser zoom?  Of the top of my head I
thought these technically weren't CSS pixels because true CSS pixels have
browser zoom applied, but I always forget the details and have to look it up
(but no longer!).

Also maybe mention the relationship to the types exposed to javascript.  Eg.
"page" (MouseEvent.pageX), "client" (MouseEvent.clientX, getBoundingClientRect),
"screen" (MouseEvent.screenX). 

[bokan, 2015/03/09 13:44:33]

You're right, I thought it didn't matter since converting between
Frame<->Contents in CSS pixels or post-scale DIPs will keep it in CSS pixels or
DIPs, but it's wrong if you try to go from CSS pixels to Viewport or Screen
using these so I've changed the comments to make this clear.
Done

+    // The following methods convert coordinates between various spaces related
+    // to this frame. Here's the definition for each coordinate space:
+    //
+    // Contents: The coordinate space of *this* FrameView's document, in CSS
+    //           pixels. The origin is the top left corner of the document.
+    //           Therefore, this is the same as Frame coordinates but does not
+    //           take the Frame's scroll offset into account.
+    //
+    // Frame: The coordinate space of *this* FrameView in CSS pixels. The origin
+    //        is the top left corner of the frame. Therefore, scrolling the
+    //        FrameView will change the Frame coordinates of elements on the
+    //        page.
+    //
+    // RootFrame: The Frame coordinates of the *top level* (i.e. main) frame.
+    //
+    // Viewport: The coordinate space of the viewport as seen by the user, in

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

nit: "visual viewport" perhaps since you use that term in all your docs /
presentations?

[bokan, 2015/03/09 13:44:33]

Done.

+    //           device independent pixels (DIPs). The origin is at the top
+    //           left corner of the browser view (Window or Screen). The
+    //           difference between Viewport and RootFrame is the
+    //           transformation applied by pinch-zoom. This is generally what
+    //           you'd use to display something relative to the user's Window
+    //           or Screen.
+    //
+    // Screen: The final screen space on the user's device, relative to the top
+    //         left corner of the screen (i.e. if we're in a Window, this will
+    //         include the window's offset from the top left of the screen).
+    //         Note that, oddly enough, it seems this is actually in DIPs rather
+    //         than physical pixels.

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

I don't think this is odd actually.  High-dpi support is intended to be totally
transparent - only things that really want to know about physical pixels should
get them.

[bokan, 2015/03/09 13:44:33]

Yah, you're right, I've removed the "oddly enough".

     IntPoint rootFrameToContents(const IntPoint&) const;
+    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.)
-    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 artifact of the
+    // 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
@@ -507,7 +539,7 @@ public:
     void windowResizerRectChanged();
 
     // For platforms that need to hit test scrollbars from within the engine's event handlers (like Win32).
-    Scrollbar* scrollbarAtWindowPoint(const IntPoint&);
+    Scrollbar* scrollbarAtRootFramePoint(const IntPoint&);
     Scrollbar* scrollbarAtFramePoint(const IntPoint&);
 
     virtual IntPoint convertChildToSelf(const Widget* child, const IntPoint& point) const override