Removed FrameView's windowToContents and contentsToWindow methods.

Source/core/frame/FrameView.h

 /*
    Copyright (C) 1997 Martin Jones (mjones@kde.org)
              (C) 1998 Waldo Bastian (bastian@kde.org)
              (C) 1998, 1999 Torben Weis (weis@kde.org)
              (C) 1999 Lars Knoll (knoll@kde.org)
              (C) 1999 Antti Koivisto (koivisto@kde.org)
    Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009 Apple Inc. All rights reserved.
 
    This library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Library General Public
@@ skipping 454 matching lines @@
 
     // Scroll the actual contents of the view (either blitting or invalidating as needed).
     void scrollContents(const IntSize& scrollDelta);
 
     // This gives us a means of blocking painting on our scrollbars until the first layout has occurred.
     void setScrollbarsSuppressed(bool suppressed, bool repaintOnUnsuppress = false);
     bool scrollbarsSuppressed() const { return m_scrollbarsSuppressed; }
 
     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
     // they are affected by scroll offset. Content coordinates are relative to the
     // document's top left corner and thus are not affected by scroll offset.
     IntPoint contentsToFrame(const IntPoint&) const;
     IntRect contentsToFrame(const IntRect&) const;
     IntPoint frameToContents(const IntPoint&) const;
     FloatPoint frameToContents(const FloatPoint&) const;
     IntRect frameToContents(const IntRect&) const;
 
     // Functions for converting to screen coordinates.
     IntRect contentsToScreen(const IntRect&) const;
 
     // These functions are used to enable scrollbars to avoid window resizer controls that overlap the scroll view.
     // This happens only on Mac OS X 10.6.
     IntRect windowResizerRect() const;
     bool containsScrollbarsAvoidingResizer() const;
     void adjustScrollbarsAvoidingResizerCount(int overlapDelta);
     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
     {
         IntPoint newPoint = point;
         if (!isFrameViewScrollbar(child))
             newPoint = contentsToFrame(point);
         newPoint.moveBy(child->location());
         return newPoint;
     }
@@ skipping 345 matching lines @@
     static const unsigned visualPixelThreshold = 32 * 32;
     if (m_visuallyNonEmptyPixelCount > visualPixelThreshold)
         setIsVisuallyNonEmpty();
 }
 
 DEFINE_TYPE_CASTS(FrameView, Widget, widget, widget->isFrameView(), widget.isFrameView());
 
 } // namespace blink
 
 #endif // FrameView_h