Adds DevTools commands for forced viewport override.

third_party/WebKit/Source/core/inspector/browser_protocol.json

 {
     "version": { "major": "1", "minor": "1" },
     "domains": [{
         "domain": "Inspector",
         "experimental": true,
         "types": [],
         "commands": [
             {
                 "name": "enable",
                 "description": "Enables inspector domain notifications.",
@@ skipping 729 matching lines @@
                     { "name": "screenOrientation", "$ref": "ScreenOrientation", "optional": true, "description": "Screen orientation override." }
                 ],
                 "handlers": ["browser"]
             },
             {
                 "name": "clearDeviceMetricsOverride",
                 "description": "Clears the overriden device metrics.",
                 "handlers": ["browser"]
             },
             {
+                "name": "setVisualTransformOverride",

[dgozman, 2016/08/18 20:11:10]

The overall approach sounds good, but I think we should use scale, offsetX and
offsetY in device metrics instead. They are meant to be used exactly for that
(e.g. centering/scaling the emulated page inside the RWHV). If we miss something
(like disabling viewport clipping), let's modify existing handling to add that.
WDYT?

[Eric Seckler, 2016/08/18 22:04:28]

Hmm, the current parameters in the device metrics override are only applied
once, and they seem really more intended as an offset within the frame at which
to show the emulated page, as you've mentioned. We could "abuse" them for our
use of placing a specific area of the page at coordinates (0,0) by supplying a
negative offset. However, that doesn't take current scroll offset / page scale
into account. (For the visual transform override, we're compensating for changes
in scroll offset / page scale to ensure we're actually showing the intended area
at intended scale at (0,0).) Plus, as you said, the other missing bits are
viewport clipping and setting the interest rect for painting/recording. Thus,
we'd need an additional boolean flag (or multiple) that, when enabled:
- makes offsetX/Y relative to page origin, and scale relative to a 1.0 page
scale.
- enables scroll/scale compensating behavior
- disables viewport clipping
- sets the recording rect according to physical backing size and override
offset/scale (see your other comment).

I was refraining from adding this to the device metrics override, since you
previously said that it's already getting rather parameter/functionality-loaden.
Plus, I felt this alternative behavior of the offsetX/Y/scale parameters might
be confusing. IMHO, having a separate command feels a bit cleaner - e.g. the
purpose & coordinate space for the params is clearer in this case. But I can see
there's some potential overlap in parameter-reuse, at least if we slightly
change their meaning ;)

Of course, reusing the offsetX/Y/scale params from the device metrics override
then makes it impossible to use them for their original purpose at the same
time. A separate visual transform override would allow for that. Don't think
we'd need that for headless though.

+                "description": "Overrides the visible area of the page in the frame. In effect, moves the specified area of the page into the top-left corner of the frame.",
+                "parameters": [
+                    { "name": "x", "type": "number", "description": "X coordinate of top-left corner of the area (CSS pixels)." },
+                    { "name": "y", "type": "number", "description": "Y coordinate of top-left corner of the area (CSS pixels)." },
+                    { "name": "width", "type": "number", "description": "Width of the area (CSS pixels)." },

[dgozman, 2016/08/18 20:11:10]

So, these are here only for optimization purpose? Can we use the physical
backing size in compositor instead (which you plan to set using RWHV resize from
another patch)? The less parameters we have the better.

[Eric Seckler, 2016/08/18 22:04:28]

We only use them to specify the interest area for painting/recording, correct.
You're right, we could probably get away with using the physical backing size
(scaled by the inverse of the supplied override scale). The physical backing
size update happens asynchronously, though, so we'd need to make sure that this
doesn't bite us.

+                    { "name": "height", "type": "number", "description": "Height of the area (CSS pixels)." },
+                    { "name": "scale", "type": "number", "optional": true, "description": "Scale to apply to the selected area (default 1.0)." }
+                ]
+            },
+            {
+                "name": "clearVisualTransformOverride",
+                "description": "Clears any active visual transform override."
+            },
+            {
                 "name": "resetPageScaleFactor",
                 "description": "Requests that page scale factor is reset to initial values."
             },
             {
                 "name": "setPageScaleFactor",
                 "description": "Sets a specified page scale factor.",
                 "parameters": [
                     { "name": "pageScaleFactor", "type": "number", "description": "Page scale factor." }
                 ]
             },
@@ skipping 3723 matching lines @@
                 "description": "Informs that port was successfully bound and got a specified connection id.",
                 "parameters": [
                     {"name": "port", "type": "integer", "description": "Port number that was successfully bound." },
                     {"name": "connectionId", "type": "string", "description": "Connection id to be used." }
                 ],
                 "handlers": ["browser"]
             }
         ]
     }]
 }