Fix inspector overlay when use-zoom-for-dsf is enabled.

Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862
Committed: https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Committed: https://crrev.com/fca01d88e345fce580cd8acc7245f6cdc89a0c84
Cr-Original-Commit-Position: refs/heads/master@{#404063}
Cr-Commit-Position: refs/heads/master@{#404285}

[Bret, 2016-06-30 18:48:11]

Description was changed from

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862
==========

to

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862
==========

[Bret, 2016-06-30 18:48:11]

bsep@chromium.org changed reviewers:
+ dgozman@chromium.org

[Bret, 2016-06-30 20:18:39]

The CQ bit was checked by bsep@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-30 20:19:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dgozman, 2016-06-30 21:07:55]

dgozman@chromium.org changed reviewers:
+ oshima@chromium.org

[dgozman, 2016-06-30 21:07:56]

We should have overlay and original page to use the same coordinate space. This
way we don't have to convert things everywhere.
@oshima: wasn't the previous fix did just that - applying the same pageZoom to
overlay page to sync them?
Can we have a description of where we are heading? I don't think that
introducing conversions in a lot of places is the way to go.

[Bret, 2016-06-30 21:18:27]

On 2016/06/30 21:07:56, dgozman wrote:
> We should have overlay and original page to use the same coordinate space.
This
> way we don't have to convert things everywhere.
> @oshima: wasn't the previous fix did just that - applying the same pageZoom to
> overlay page to sync them?
> Can we have a description of where we are heading? I don't think that
> introducing conversions in a lot of places is the way to go.

It did seem a bit odd to me that the "setPageZoomFactor" call in
InspectorOverlay::rebuildOverlayPage didn't solve this problem already. I guess
the points for the path are being calculated based on window coordinates? Which
would mean we have to do a conversion somewhere. At least this patch seems to
solve all the problems I can find, so I don't think we'd need to introduce any
more conversions after this.

[commit-bot: I haz the power, 2016-06-30 21:24:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-30 21:24:26]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[oshima, 2016-07-01 12:03:18]

My patch makes overlay and browser UI to use the same scale.

The original page can have its own zoom level, so it may not have the same
devicePixelRatio.

The way it works (as I understand) is that

* The overlay page uses css scale to draw UI.
* The original page generate path in the viewport scale. This works now because
  viewport scale == DIP == css without user zoom.
* With use-zoom-for-dsf, the viewport scale becomes native pixel, so viewport
scale == css * scale used by use-zoom-for-dsf.

and that's why it has to be divided.

Alternative way is to change the code that generate the path, but that seems to
be more complicated.

https://codereview.chromium.org/2108803006/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/InspectorOverlay.cpp (right):

https://codereview.chromium.org/2108803006/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/InspectorOverlay.cpp:428: InspectorHighlight
highlight(element, m_nodeHighlightConfig, false, windowToViewportScale());
can you pass this value in resetData instead? That way, you don't have to change
in other inspector cpp, I think.

[Bret, 2016-07-01 18:24:36]

https://codereview.chromium.org/2108803006/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/InspectorOverlay.cpp (right):

https://codereview.chromium.org/2108803006/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/InspectorOverlay.cpp:428: InspectorHighlight
highlight(element, m_nodeHighlightConfig, false, windowToViewportScale());
On 2016/07/01 12:03:18, oshima wrote:
> can you pass this value in resetData instead? That way, you don't have to
change
> in other inspector cpp, I think.

Ah yes, that's better. Done.

[Bret, 2016-07-01 18:24:58]

The CQ bit was checked by bsep@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-01 18:25:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-01 19:41:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-01 19:41:13]

Dry run: This issue passed the CQ dry run.

[oshima, 2016-07-01 20:48:45]

https://codereview.chromium.org/2108803006/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/inspector/LayoutEditor.cpp (right):

https://codereview.chromium.org/2108803006/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/inspector/LayoutEditor.cpp:12: #include
"core/css/CSSStyleSheet.h"
revert this file?

[Bret, 2016-07-02 00:17:52]

https://codereview.chromium.org/2108803006/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/inspector/LayoutEditor.cpp (right):

https://codereview.chromium.org/2108803006/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/inspector/LayoutEditor.cpp:12: #include
"core/css/CSSStyleSheet.h"
On 2016/07/01 20:48:45, oshima wrote:
> revert this file?

My bad. Done.

[dgozman, 2016-07-05 18:01:42]

dgozman@chromium.org changed reviewers:
+ bokan@chromium.org

[dgozman, 2016-07-05 18:01:43]

[+bokan for viewport]

On 2016/07/01 12:03:18, oshima wrote:
> My patch makes overlay and browser UI to use the same scale.
> 
> The original page can have its own zoom level, so it may not have the same
> devicePixelRatio.
> 
> The way it works (as I understand) is that
> 
> * The overlay page uses css scale to draw UI.
> * The original page generate path in the viewport scale. This works now
because
>   viewport scale == DIP == css without user zoom.
> * With use-zoom-for-dsf, the viewport scale becomes native pixel, so viewport
> scale == css * scale used by use-zoom-for-dsf.
> 
> and that's why it has to be divided.
> 
> Alternative way is to change the code that generate the path, but that seems
to
> be more complicated.

I think we should go this way instead. All conversions are done in
InspectorHighlight.cpp, where we use FrameView::contentsToViewport method. In
fact, why don't we support zoom-for-dsf there? It's very unfortunate that every
place dealing with coordinates has to take both viewport and new zoom into
account.

@bokan: wdyt about converging viewport transforms with zoom-for-dsf?

[bokan, 2016-07-05 23:41:03]

On 2016/07/05 18:01:43, dgozman wrote:
> [+bokan for viewport]
> 
> On 2016/07/01 12:03:18, oshima wrote:
> > My patch makes overlay and browser UI to use the same scale.
> > 
> > The original page can have its own zoom level, so it may not have the same
> > devicePixelRatio.
> > 
> > The way it works (as I understand) is that
> > 
> > * The overlay page uses css scale to draw UI.
> > * The original page generate path in the viewport scale. This works now
> because
> >   viewport scale == DIP == css without user zoom.
> > * With use-zoom-for-dsf, the viewport scale becomes native pixel, so
viewport
> > scale == css * scale used by use-zoom-for-dsf.
> > 
> > and that's why it has to be divided.
> > 
> > Alternative way is to change the code that generate the path, but that seems
> to
> > be more complicated.
> 
> I think we should go this way instead. All conversions are done in
> InspectorHighlight.cpp, where we use FrameView::contentsToViewport method. In
> fact, why don't we support zoom-for-dsf there? It's very unfortunate that
every
> place dealing with coordinates has to take both viewport and new zoom into
> account.
> 
> @bokan: wdyt about converging viewport transforms with zoom-for-dsf?

Do you mean making it so that FrameView::contentsToViewport(x) takes x in CSS
pixels and outputs in physical pixels? My understanding of zoom-for-dsf is that
all internal blink positions will now be in physical pixels and so all these
conversion functions should be physical<->physical since it's used commonly
within Blink. The only place where we should be applying CSS zoom is at web API
boundaries before coming in or going out of Blink. I suspect that the inspector
is using web APIs and so you're getting values with CSS zoom applied but not
DFS? My recommendation would be to fix this where it goes from the Inspector
into Blink, I believe that's InspectorHighlight.cpp as you mention.

BTW, this seems like another good motivating example for crbug.com/417560. This
would all be more clear if we have a type system to annotate what kinds of
coordinates we're dealing with. Then the compiler could check that our
conversions are correct.

[Bret, 2016-07-06 19:38:19]

On 2016/07/05 23:41:03, bokan wrote:
> On 2016/07/05 18:01:43, dgozman wrote:
> > [+bokan for viewport]
> > 
> > On 2016/07/01 12:03:18, oshima wrote:
> > > My patch makes overlay and browser UI to use the same scale.
> > > 
> > > The original page can have its own zoom level, so it may not have the same
> > > devicePixelRatio.
> > > 
> > > The way it works (as I understand) is that
> > > 
> > > * The overlay page uses css scale to draw UI.
> > > * The original page generate path in the viewport scale. This works now
> > because
> > >   viewport scale == DIP == css without user zoom.
> > > * With use-zoom-for-dsf, the viewport scale becomes native pixel, so
> viewport
> > > scale == css * scale used by use-zoom-for-dsf.
> > > 
> > > and that's why it has to be divided.
> > > 
> > > Alternative way is to change the code that generate the path, but that
seems
> > to
> > > be more complicated.
> > 
> > I think we should go this way instead. All conversions are done in
> > InspectorHighlight.cpp, where we use FrameView::contentsToViewport method.
In
> > fact, why don't we support zoom-for-dsf there? It's very unfortunate that
> every
> > place dealing with coordinates has to take both viewport and new zoom into
> > account.
> > 
> > @bokan: wdyt about converging viewport transforms with zoom-for-dsf?
> 
> Do you mean making it so that FrameView::contentsToViewport(x) takes x in CSS
> pixels and outputs in physical pixels? My understanding of zoom-for-dsf is
that
> all internal blink positions will now be in physical pixels and so all these
> conversion functions should be physical<->physical since it's used commonly
> within Blink. The only place where we should be applying CSS zoom is at web
API
> boundaries before coming in or going out of Blink. I suspect that the
inspector
> is using web APIs and so you're getting values with CSS zoom applied but not
> DFS? My recommendation would be to fix this where it goes from the Inspector
> into Blink, I believe that's InspectorHighlight.cpp as you mention.
> 
> BTW, this seems like another good motivating example for crbug.com/417560.
This
> would all be more clear if we have a type system to annotate what kinds of
> coordinates we're dealing with. Then the compiler could check that our
> conversions are correct.

So if I understand this discussion correctly, you want me to not change
InspectorOverlayPage.html at all and instead convert the path coordinates as
they're calculated, in InspectorHighlight's PathBuilder? That seems doable, but
it'll be a more complicated change.

[dgozman, 2016-07-06 19:40:22]

On 2016/07/06 19:38:19, Bret Sepulveda wrote:
> On 2016/07/05 23:41:03, bokan wrote:
> > On 2016/07/05 18:01:43, dgozman wrote:
> > > [+bokan for viewport]
> > > 
> > > On 2016/07/01 12:03:18, oshima wrote:
> > > > My patch makes overlay and browser UI to use the same scale.
> > > > 
> > > > The original page can have its own zoom level, so it may not have the
same
> > > > devicePixelRatio.
> > > > 
> > > > The way it works (as I understand) is that
> > > > 
> > > > * The overlay page uses css scale to draw UI.
> > > > * The original page generate path in the viewport scale. This works now
> > > because
> > > >   viewport scale == DIP == css without user zoom.
> > > > * With use-zoom-for-dsf, the viewport scale becomes native pixel, so
> > viewport
> > > > scale == css * scale used by use-zoom-for-dsf.
> > > > 
> > > > and that's why it has to be divided.
> > > > 
> > > > Alternative way is to change the code that generate the path, but that
> seems
> > > to
> > > > be more complicated.
> > > 
> > > I think we should go this way instead. All conversions are done in
> > > InspectorHighlight.cpp, where we use FrameView::contentsToViewport method.
> In
> > > fact, why don't we support zoom-for-dsf there? It's very unfortunate that
> > every
> > > place dealing with coordinates has to take both viewport and new zoom into
> > > account.
> > > 
> > > @bokan: wdyt about converging viewport transforms with zoom-for-dsf?
> > 
> > Do you mean making it so that FrameView::contentsToViewport(x) takes x in
CSS
> > pixels and outputs in physical pixels? My understanding of zoom-for-dsf is
> that
> > all internal blink positions will now be in physical pixels and so all these
> > conversion functions should be physical<->physical since it's used commonly
> > within Blink. The only place where we should be applying CSS zoom is at web
> API
> > boundaries before coming in or going out of Blink. I suspect that the
> inspector
> > is using web APIs and so you're getting values with CSS zoom applied but not
> > DFS? My recommendation would be to fix this where it goes from the Inspector
> > into Blink, I believe that's InspectorHighlight.cpp as you mention.
> > 
> > BTW, this seems like another good motivating example for crbug.com/417560.
> This
> > would all be more clear if we have a type system to annotate what kinds of
> > coordinates we're dealing with. Then the compiler could check that our
> > conversions are correct.
> 
> So if I understand this discussion correctly, you want me to not change
> InspectorOverlayPage.html at all and instead convert the path coordinates as
> they're calculated, in InspectorHighlight's PathBuilder? That seems doable,
but
> it'll be a more complicated change.

Correct. I think that would be better.

[Bret, 2016-07-06 22:30:22]

On 2016/07/06 19:40:22, dgozman wrote:
> On 2016/07/06 19:38:19, Bret Sepulveda wrote:
> > On 2016/07/05 23:41:03, bokan wrote:
> > > On 2016/07/05 18:01:43, dgozman wrote:
> > > > [+bokan for viewport]
> > > > 
> > > > On 2016/07/01 12:03:18, oshima wrote:
> > > > > My patch makes overlay and browser UI to use the same scale.
> > > > > 
> > > > > The original page can have its own zoom level, so it may not have the
> same
> > > > > devicePixelRatio.
> > > > > 
> > > > > The way it works (as I understand) is that
> > > > > 
> > > > > * The overlay page uses css scale to draw UI.
> > > > > * The original page generate path in the viewport scale. This works
now
> > > > because
> > > > >   viewport scale == DIP == css without user zoom.
> > > > > * With use-zoom-for-dsf, the viewport scale becomes native pixel, so
> > > viewport
> > > > > scale == css * scale used by use-zoom-for-dsf.
> > > > > 
> > > > > and that's why it has to be divided.
> > > > > 
> > > > > Alternative way is to change the code that generate the path, but that
> > seems
> > > > to
> > > > > be more complicated.
> > > > 
> > > > I think we should go this way instead. All conversions are done in
> > > > InspectorHighlight.cpp, where we use FrameView::contentsToViewport
method.
> > In
> > > > fact, why don't we support zoom-for-dsf there? It's very unfortunate
that
> > > every
> > > > place dealing with coordinates has to take both viewport and new zoom
into
> > > > account.
> > > > 
> > > > @bokan: wdyt about converging viewport transforms with zoom-for-dsf?
> > > 
> > > Do you mean making it so that FrameView::contentsToViewport(x) takes x in
> CSS
> > > pixels and outputs in physical pixels? My understanding of zoom-for-dsf is
> > that
> > > all internal blink positions will now be in physical pixels and so all
these
> > > conversion functions should be physical<->physical since it's used
commonly
> > > within Blink. The only place where we should be applying CSS zoom is at
web
> > API
> > > boundaries before coming in or going out of Blink. I suspect that the
> > inspector
> > > is using web APIs and so you're getting values with CSS zoom applied but
not
> > > DFS? My recommendation would be to fix this where it goes from the
Inspector
> > > into Blink, I believe that's InspectorHighlight.cpp as you mention.
> > > 
> > > BTW, this seems like another good motivating example for crbug.com/417560.
> > This
> > > would all be more clear if we have a type system to annotate what kinds of
> > > coordinates we're dealing with. Then the compiler could check that our
> > > conversions are correct.
> > 
> > So if I understand this discussion correctly, you want me to not change
> > InspectorOverlayPage.html at all and instead convert the path coordinates as
> > they're calculated, in InspectorHighlight's PathBuilder? That seems doable,
> but
> > it'll be a more complicated change.
> 
> Correct. I think that would be better.

This is done, ptal.

[dgozman, 2016-07-06 22:37:35]

This is much better I think!

https://codereview.chromium.org/2108803006/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/inspector/InspectorHighlight.h (right):

https://codereview.chromium.org/2108803006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/inspector/InspectorHighlight.h:48:
InspectorHighlight(Node*, const InspectorHighlightConfig&, bool
appendElementInfo, float highlightScale);
I think we should not pass it, but rather grab it from FrameView, as we do with
contentsToViewport.

https://codereview.chromium.org/2108803006/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/inspector/LayoutEditor.cpp (right):

https://codereview.chromium.org/2108803006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/inspector/LayoutEditor.cpp:398:
InspectorHighlight highlight(element, config, false, 1.f);
This should be the same ratio as in InspectorOverlay.

[Bret, 2016-07-06 23:38:02]

https://codereview.chromium.org/2108803006/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/inspector/InspectorHighlight.h (right):

https://codereview.chromium.org/2108803006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/inspector/InspectorHighlight.h:48:
InspectorHighlight(Node*, const InspectorHighlightConfig&, bool
appendElementInfo, float highlightScale);
On 2016/07/06 22:37:35, dgozman wrote:
> I think we should not pass it, but rather grab it from FrameView, as we do
with
> contentsToViewport.

Done.

https://codereview.chromium.org/2108803006/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/inspector/LayoutEditor.cpp (right):

https://codereview.chromium.org/2108803006/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/inspector/LayoutEditor.cpp:398:
InspectorHighlight highlight(element, config, false, 1.f);
On 2016/07/06 22:37:35, dgozman wrote:
> This should be the same ratio as in InspectorOverlay.

Fixed incidentally as part of plumbing the value through FrameView instead. But
as far as I can tell LayoutEditor is an abandoned feature, since it's
well-hidden and doesn't seem to work.

[Bret, 2016-07-06 23:38:13]

The CQ bit was checked by bsep@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-06 23:38:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dgozman, 2016-07-07 00:30:10]

lgtm with comments

> Fixed incidentally as part of plumbing the value through FrameView instead.
But
> as far as I can tell LayoutEditor is an abandoned feature, since it's
> well-hidden and doesn't seem to work.
Yeah, it's paused for now.

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/FrameView.h (right):

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/FrameView.h:511: float
viewportToWindowScale() const;
Let's not introduce this method, it will encourage the use of it. Just inline it
in call places.

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/inspector/InspectorHighlight.h (right):

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/inspector/InspectorHighlight.h:49:
InspectorHighlight(float highlightScale);
style: explicit

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/inspector/InspectorHighlight.h:70: float
m_highlightScale;
Just m_scale. It's already a highlight object.

[Bret, 2016-07-07 01:15:11]

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/FrameView.h (right):

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/FrameView.h:511: float
viewportToWindowScale() const;
On 2016/07/07 00:30:09, dgozman wrote:
> Let's not introduce this method, it will encourage the use of it. Just inline
it
> in call places.

Done.

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/inspector/InspectorHighlight.h (right):

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/inspector/InspectorHighlight.h:49:
InspectorHighlight(float highlightScale);
On 2016/07/07 00:30:09, dgozman wrote:
> style: explicit

Done.

https://codereview.chromium.org/2108803006/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/inspector/InspectorHighlight.h:70: float
m_highlightScale;
On 2016/07/07 00:30:10, dgozman wrote:
> Just m_scale. It's already a highlight object.

Done. Changed in PathBuilder::appendPath and ShapePathBuilder::buildPath too.

[Bret, 2016-07-07 01:15:24]

The CQ bit was checked by bsep@chromium.org

[Bret, 2016-07-07 01:15:24]

The patchset sent to the CQ was uploaded after l-g-t-m from dgozman@chromium.org
Link to the patchset: https://codereview.chromium.org/2108803006/#ps140001
(title: "address comments")

[commit-bot: I haz the power, 2016-07-07 01:16:07]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-07 03:35:10]

Description was changed from

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862
==========

to

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862
==========

[commit-bot: I haz the power, 2016-07-07 03:35:12]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-07-07 03:35:28]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-07 03:37:33]

Description was changed from

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862
==========

to

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862

Committed: https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Cr-Commit-Position: refs/heads/master@{#404063}
==========

[commit-bot: I haz the power, 2016-07-07 03:37:35]

Patchset 8 (id:??) landed as
https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Cr-Commit-Position: refs/heads/master@{#404063}

[tkent, 2016-07-07 06:48:46]

A revert of this CL (patchset #8 id:140001) has been created in
https://codereview.chromium.org/2127053002/ by tkent@chromium.org.

The reason for reverting is:
inspector/elements/shadow/elements-panel-shadow-selection-on-refresh-1.html is
crashy after this change.

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpec...
.

[Bret, 2016-07-07 21:31:27]

Description was changed from

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862

Committed: https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Cr-Commit-Position: refs/heads/master@{#404063}
==========

to

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862

Committed: https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Cr-Commit-Position: refs/heads/master@{#404063}
==========

[Bret, 2016-07-07 21:32:00]

The CQ bit was checked by bsep@chromium.org

[Bret, 2016-07-07 21:32:00]

The patchset sent to the CQ was uploaded after l-g-t-m from dgozman@chromium.org
Link to the patchset: https://codereview.chromium.org/2108803006/#ps160001
(title: "fix crash when FrameView is null")

[commit-bot: I haz the power, 2016-07-07 21:33:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-07 23:36:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-07 23:36:15]

Try jobs failed on following builders:
  mac_chromium_gyp_rel on master.tryserver.chromium.mac (JOB_TIMED_OUT, no build
URL)

[Bret, 2016-07-07 23:46:58]

The CQ bit was checked by bsep@chromium.org

[commit-bot: I haz the power, 2016-07-07 23:47:28]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-08 01:03:53]

Description was changed from

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862

Committed: https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Cr-Commit-Position: refs/heads/master@{#404063}
==========

to

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862

Committed: https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Cr-Commit-Position: refs/heads/master@{#404063}
==========

[commit-bot: I haz the power, 2016-07-08 01:03:55]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-07-08 01:04:13]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-08 01:05:49]

Description was changed from

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862

Committed: https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Cr-Commit-Position: refs/heads/master@{#404063}
==========

to

==========
Fix inspector overlay when use-zoom-for-dsf is enabled.

Inspector overlays were misaligned because the path points were drawing
in window coordinates and needed to be scaled to viewport coordinates.
Should be no change when use-zoom-for-dsf is off.

BUG=622862

Committed: https://crrev.com/6651b97ebd509e97bea8929303738dc20a3ed880
Committed: https://crrev.com/fca01d88e345fce580cd8acc7245f6cdc89a0c84
Cr-Original-Commit-Position: refs/heads/master@{#404063}
Cr-Commit-Position: refs/heads/master@{#404285}
==========

[commit-bot: I haz the power, 2016-07-08 01:05:50]

Patchset 9 (id:??) landed as
https://crrev.com/fca01d88e345fce580cd8acc7245f6cdc89a0c84
Cr-Commit-Position: refs/heads/master@{#404285}