Move handling of DraggableRegionsChanged notification from "view" to "frame".

Move handling of DraggableRegionsChanged notification from "view" to "frame".

This CL:
- Moves AnnotatedRegionsChanged method from blink::ChromeClient to
  blink::LocalFrameClient
- Moves DraggableRegionsChanged method from blink::WebViewClient to
  blink::WebFrameClient
- Move DraggableRegionsChanged method from content::RenderViewObserver
  to content::RenderFrameObserver
- Moves handling of DraggableRegionsChanged from
  extensions::ExtensionHelper (a content::RenderViewObserver) to
  extensions::ExtensionFrameHelper (a content::RenderFrameObserver).
- Tweaks AppWindowContentsImpl::OnMessageReceived so that it is aware
  which RenderFrameHost sent the ExtensionHostMsg_UpdateDraggableRegions
  IPC.

These changes mean that the originating local frame is no longer lost in
the middle of the notification chain (and that hopefully/speculatively
we will no longer crash by trying to look into a wrong, remote frame
as observed in bug https://crbug.com/645472).

BUG=645472
Review-Url: https://codereview.chromium.org/2929493003
Cr-Commit-Position: refs/heads/master@{#479195}
Committed: https://chromium.googlesource.com/chromium/src/+/060c739be2660ac6903b8af1d1585d7eac6bfe25

[Łukasz Anforowicz, 2017-06-06 22:31:13]

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

[commit-bot: I haz the power, 2017-06-06 22:31:37]

Dry run: CQ is trying da patch.

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

[Łukasz Anforowicz, 2017-06-06 22:41:34]

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

[commit-bot: I haz the power, 2017-06-06 22:41:57]

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, 2017-06-06 22:53:06]

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

[commit-bot: I haz the power, 2017-06-06 22:53:07]

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

[Łukasz Anforowicz, 2017-06-07 00:03:06]

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

[commit-bot: I haz the power, 2017-06-07 00:03:30]

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, 2017-06-07 02:41:26]

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

[commit-bot: I haz the power, 2017-06-07 02:41:27]

Dry run: This issue passed the CQ dry run.

[Łukasz Anforowicz, 2017-06-07 18:25:02]

lukasza@chromium.org changed reviewers:
+ dcheng@chromium.org

[Łukasz Anforowicz, 2017-06-07 18:25:04]

dcheng@, could you take a first stab at reviewing this CL (initially I thought
about alexmos@, but AFAIK he is OOO today and besides - this CL touches quite a
few things in Blink).

- I think moving these things from "view" to "frame" makes a lot of sense (even
if hypothetically we figure out how to unship this feature at a later time).

- Landing this CL should help avoid OOPIF-related crashes (and should pave way
for broader Finch trials of various OOPIF modes).  I hope this is sufficient
motivation to land this CL without worrying too much about existing test
coverage (described in another comment below).

https://codereview.chromium.org/2929493003/diff/40001/extensions/browser/app_...
File extensions/browser/app_window/app_window_contents.cc (left):

https://codereview.chromium.org/2929493003/diff/40001/extensions/browser/app_...
extensions/browser/app_window/app_window_contents.cc:117: const
std::vector<DraggableRegion>& regions) {
Test coverage of this CL is not that great:

- There is *some* test coverage - some tests crash if I insert a CHECK(false)
here (e.g. LaunchWebAuthFlowFunctionTest).

- OTOH, the test coverage is superficial - no tests fail if I just return early
here.


I hope it is okay to depend on the limited test coverage described above and
then monitor crash rates (which should hopefully go down after this CL for
https://crbug.com/645472 - blink::WebDocument::draggableRegions).

I guess that in theory we could say that we'll add test coverage in a follow-up
CL, but I'd rather not sign up for that and so the promise of the follow-up test
coverage would be rather hollow... :-/

[dcheng, 2017-06-07 20:22:35]

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/LocalFrameView.cpp (right):

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/LocalFrameView.cpp:2826: if
(frame_->Client())
I strongly suspect that this should be a DCHECK--this is getting called on the
FrameView, which is set to null during detach (so this wouldn't be reachable)

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/LocalFrameClientImpl.cpp (right):

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/LocalFrameClientImpl.cpp:1056: if
(web_frame_->Client())
Nit: no null check needed here, if LocalFrameClient is reachable, WebFrameClient
must be (with one exception, but this code shouldn't hit it)

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/publ...
File third_party/WebKit/public/web/WebFrameClient.h (right):

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/publ...
third_party/WebKit/public/web/WebFrameClient.h:804: // Other methods
--------------------------------------------------------
Nit: let's just call this Draggable regions still, despite the fact that it's
basically a one-off method. Alternatively, we could consider grouping it under
Geometry methods.

[Łukasz Anforowicz, 2017-06-07 21:48:18]

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

[commit-bot: I haz the power, 2017-06-07 21:48:51]

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, 2017-06-07 21:52:30]

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

[commit-bot: I haz the power, 2017-06-07 21:52:33]

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

[Łukasz Anforowicz, 2017-06-07 21:59:25]

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

[commit-bot: I haz the power, 2017-06-07 21:59:52]

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, 2017-06-08 00:15:38]

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

[commit-bot: I haz the power, 2017-06-08 00:15:39]

Dry run: This issue passed the CQ dry run.

[Łukasz Anforowicz, 2017-06-08 16:29:24]

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/LocalFrameView.cpp (right):

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/LocalFrameView.cpp:2826: if
(frame_->Client())
On 2017/06/07 20:22:35, dcheng wrote:
> I strongly suspect that this should be a DCHECK--this is getting called on the
> FrameView, which is set to null during detach (so this wouldn't be reachable)

Done (I've also added a comment - please shout if the comment includes too much
information [i.e. if the comment is likely to become stale / out-of-sync] and if
I should remove or reword the comment).

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/LocalFrameClientImpl.cpp (right):

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/LocalFrameClientImpl.cpp:1056: if
(web_frame_->Client())
On 2017/06/07 20:22:35, dcheng wrote:
> Nit: no null check needed here, if LocalFrameClient is reachable,
WebFrameClient
> must be (with one exception, but this code shouldn't hit it)

Done - thanks for pointing this out (I was just cargo-culting from the
surrounding methods and noticed that some of them do check for nullness).

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/publ...
File third_party/WebKit/public/web/WebFrameClient.h (right):

https://codereview.chromium.org/2929493003/diff/40001/third_party/WebKit/publ...
third_party/WebKit/public/web/WebFrameClient.h:804: // Other methods
--------------------------------------------------------
On 2017/06/07 20:22:35, dcheng wrote:
> Nit: let's just call this Draggable regions still, despite the fact that it's
> basically a one-off method. Alternatively, we could consider grouping it under
> Geometry methods.

Done:
- I've moved the declaration into "Geometry notifications" section
- I've also changed "Other methods" in WebViewClient.h to "Gestures".

[dcheng, 2017-06-08 20:02:56]

lgtm

https://codereview.chromium.org/2929493003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/LocalFrameView.cpp (right):

https://codereview.chromium.org/2929493003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/LocalFrameView.cpp:2827: // during detach
(LocalFrame::Detach calls SetView(nullptr)).
I would omit this comment: the precise details of this are likely to change over
time. I plan on documenting lifecycle things more thoroughly in a separate
README.md file.

[Łukasz Anforowicz, 2017-06-08 20:51:33]

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

[Łukasz Anforowicz, 2017-06-08 20:51:37]

https://codereview.chromium.org/2929493003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/LocalFrameView.cpp (right):

https://codereview.chromium.org/2929493003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/LocalFrameView.cpp:2827: // during detach
(LocalFrame::Detach calls SetView(nullptr)).
On 2017/06/08 20:02:56, dcheng wrote:
> I would omit this comment: the precise details of this are likely to change
over
> time. I plan on documenting lifecycle things more thoroughly in a separate
> README.md file.

Done.

[Łukasz Anforowicz, 2017-06-08 20:52:01]

lukasza@chromium.org changed reviewers:
+ alexmos@chromium.org

[Łukasz Anforowicz, 2017-06-08 20:52:02]

alexmos@, can you PTAL?

[commit-bot: I haz the power, 2017-06-08 20:52:04]

Dry run: CQ is trying da patch.

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

[alexmos, 2017-06-08 21:19:00]

content/ LGTM but one question in the extensions code.

https://codereview.chromium.org/2929493003/diff/100001/extensions/renderer/ex...
File extensions/renderer/extension_frame_helper.cc (right):

https://codereview.chromium.org/2929493003/diff/100001/extensions/renderer/ex...
extensions/renderer/extension_frame_helper.cc:345:
render_frame()->GetRenderView()->ConvertViewportToWindowViaWidget(
Is this going to work for a swapped-out RenderView?  I would think this should
instead use something like
render_frame()->GetRenderWidget()->ConvertViewportToWindow(), though we don't
publicly expose RenderWidget. :(  I don't know if there's a behavioral
difference in practice for the conversion (e.g., I don't remember if we set
things like GetOriginalDeviceScaleFactor for swapped-out RVs or not).  James or
Ken would probably know.

[Łukasz Anforowicz, 2017-06-08 22:27:12]

lukasza@chromium.org changed reviewers:
+ kenrb@chromium.org

[Łukasz Anforowicz, 2017-06-08 22:27:13]

Thanks!  kenrb@ - could you please look at the question below?

https://codereview.chromium.org/2929493003/diff/100001/extensions/renderer/ex...
File extensions/renderer/extension_frame_helper.cc (right):

https://codereview.chromium.org/2929493003/diff/100001/extensions/renderer/ex...
extensions/renderer/extension_frame_helper.cc:345:
render_frame()->GetRenderView()->ConvertViewportToWindowViaWidget(
On 2017/06/08 21:19:00, alexmos wrote:
> Is this going to work for a swapped-out RenderView?  I would think this should
> instead use something like
> render_frame()->GetRenderWidget()->ConvertViewportToWindow(), though we don't
> publicly expose RenderWidget. :(  I don't know if there's a behavioral
> difference in practice for the conversion (e.g., I don't remember if we set
> things like GetOriginalDeviceScaleFactor for swapped-out RVs or not).  James
or
> Ken would probably know.

Thanks for catching this.

I guess one option would be to bail out early if the main frame is not a local
frame.  (before this CL, such situation would result in a crash).

Ken: Could you please comment on what to do here?

[commit-bot: I haz the power, 2017-06-08 23:11:15]

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

[commit-bot: I haz the power, 2017-06-08 23:11:16]

Dry run: This issue passed the CQ dry run.

[kenrb, 2017-06-09 15:43:25]

https://codereview.chromium.org/2929493003/diff/100001/extensions/renderer/ex...
File extensions/renderer/extension_frame_helper.cc (right):

https://codereview.chromium.org/2929493003/diff/100001/extensions/renderer/ex...
extensions/renderer/extension_frame_helper.cc:345:
render_frame()->GetRenderView()->ConvertViewportToWindowViaWidget(
On 2017/06/08 22:27:13, Łukasz A. wrote:
> On 2017/06/08 21:19:00, alexmos wrote:
> > Is this going to work for a swapped-out RenderView?  I would think this
should
> > instead use something like
> > render_frame()->GetRenderWidget()->ConvertViewportToWindow(), though we
don't
> > publicly expose RenderWidget. :(  I don't know if there's a behavioral
> > difference in practice for the conversion (e.g., I don't remember if we set
> > things like GetOriginalDeviceScaleFactor for swapped-out RVs or not).  James
> or
> > Ken would probably know.
> 
> Thanks for catching this.
> 
> I guess one option would be to bail out early if the main frame is not a local
> frame.  (before this CL, such situation would result in a crash).
> 
> Ken: Could you please comment on what to do here?

As far as I know, using ConvertViewportToWindowViaWidget() usage should be okay.
Swapped-out RenderViews should still get Resize messages with correct
ResizeParams. In Blink the information gets a bit sparser because WebViewImpl's
resize code bails early when mainFrame() is remote, but in content/ the
information is there.

A second question I see is whether, in an OOPIF process, the
Document::DraggableRegions() actually returns regions in Viewport coordinates,
which this code assumes when it converts from Viewport to Window coords. I just
took a quick look at the code, and I think the answer is (mostly) yes, which was
a happy surprise. I think that works because of the IntersectionObserver changes
I landed earlier this year, which taught Blink layout code to successfully map
coords to the root viewport. I say 'mostly yes' because there might be skew if
there are transforms applied to the OOPIF by the embedding frame. We don't
currently take that into account.

[Łukasz Anforowicz, 2017-06-09 18:28:10]

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

[commit-bot: I haz the power, 2017-06-09 18:28:45]

Dry run: CQ is trying da patch.

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

[Łukasz Anforowicz, 2017-06-09 18:31:20]

I've tweaked ExtensionFrameHelper::DraggableRegionsChanged so that it only
processes notifications from a main frame (and exits early otherwise).

This should be closer to the behavior before this CL (where ExtensionHelper was
always processing draggable regions of the main frame - even if the notification
originated from a different subframe, RenderViewImpl would always call:
observer.DraggableRegionsChanged(webview()->MainFrame());).

Additionally this should preemptively avoid any potential concerns about
coordinate spaces.

[Łukasz Anforowicz, 2017-06-09 20:49:37]

Patchset #8 (id:140001) has been deleted

[Łukasz Anforowicz, 2017-06-09 20:49:45]

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

[commit-bot: I haz the power, 2017-06-09 20:50:13]

Dry run: CQ is trying da patch.

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

[dcheng, 2017-06-09 22:21:54]

https://codereview.chromium.org/2929493003/diff/160001/content/public/rendere...
File content/public/renderer/render_frame_observer.h (right):

https://codereview.chromium.org/2929493003/diff/160001/content/public/rendere...
content/public/renderer/render_frame_observer.h:128: virtual void
DraggableRegionsChanged() {}
I wonder if it's worth noting this is main frame only.

https://codereview.chromium.org/2929493003/diff/160001/third_party/WebKit/pub...
File third_party/WebKit/public/web/WebFrameClient.h (right):

https://codereview.chromium.org/2929493003/diff/160001/third_party/WebKit/pub...
third_party/WebKit/public/web/WebFrameClient.h:653: virtual void
DraggableRegionsChanged() {}
Similarly, I wonder if it's worth calling out notifications that are main-frame
only here.

[commit-bot: I haz the power, 2017-06-09 22:37:50]

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

[commit-bot: I haz the power, 2017-06-09 22:37:51]

Dry run: This issue passed the CQ dry run.

[Łukasz Anforowicz, 2017-06-13 18:24:10]

https://codereview.chromium.org/2929493003/diff/160001/content/public/rendere...
File content/public/renderer/render_frame_observer.h (right):

https://codereview.chromium.org/2929493003/diff/160001/content/public/rendere...
content/public/renderer/render_frame_observer.h:128: virtual void
DraggableRegionsChanged() {}
On 2017/06/09 22:21:54, dcheng wrote:
> I wonder if it's worth noting this is main frame only.

Maybe.  We talked about this today and this sounds like something that we might
want to consider outside of this CL.

If we do want to note that some notifications (DraggableRegionsChanged,
DidChangeIcon) are (or can be) for main-frame only, then what options do we
have?

1) comments + DCHECKs?

2) WebMainFrameClient (a subclass of WebFrameClient)?

3) Some other option?

Also - how many notifications are we talking about?  You mentioned that in
addition to DraggableRegionsChanged and DidChangeIcon there was also something
about manifests - maybe you meant DidChangeManifest?  Are there other such
notifications?  Are there some non-notification things that are main-frame-only
and that don't belong in Page and/or WebView (and being non-notifications
probably don't belong in Web[Main]FrameClient)?

[Łukasz Anforowicz, 2017-06-13 18:26:08]

lukasza@chromium.org changed reviewers:
+ rdevlin.cronin@chromium.org

[Łukasz Anforowicz, 2017-06-13 18:26:08]

rdevlin.cronin@, can you PTAL?

[Devlin, 2017-06-13 18:38:31]

lgtm!

Thanks for the cleanup :)

https://codereview.chromium.org/2929493003/diff/160001/extensions/renderer/ex...
File extensions/renderer/extension_frame_helper.cc (right):

https://codereview.chromium.org/2929493003/diff/160001/extensions/renderer/ex...
extensions/renderer/extension_frame_helper.cc:346: for (size_t i = 0; i <
webregions.size(); ++i) {
update this to const blink::WebDraggableRegion&

https://codereview.chromium.org/2929493003/diff/160001/extensions/renderer/ex...
extensions/renderer/extension_frame_helper.cc:347: DraggableRegion region;
A minor optimization here would be something like:
regions.push_back(DraggableRegion());
DraggableRegion& region = regions.back();

That way we avoid the copy/assignment.

Option 2 would be adding move semantics to DraggableRegion, which would also be
okay.

[Łukasz Anforowicz, 2017-06-13 20:45:31]

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

[commit-bot: I haz the power, 2017-06-13 20:46:20]

Dry run: CQ is trying da patch.

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

[Łukasz Anforowicz, 2017-06-13 20:48:42]

Thanks for the reviews everyone!

https://codereview.chromium.org/2929493003/diff/160001/extensions/renderer/ex...
File extensions/renderer/extension_frame_helper.cc (right):

https://codereview.chromium.org/2929493003/diff/160001/extensions/renderer/ex...
extensions/renderer/extension_frame_helper.cc:346: for (size_t i = 0; i <
webregions.size(); ++i) {
On 2017/06/13 18:38:30, Devlin wrote:
> update this to const blink::WebDraggableRegion&

Done, good point.  (non-const ref, because ConvertViewport... needs to mutate
vector elements;  I've considered using const-ref and then mutating a local
blink::WebRect, but that would involve copying it later which would run counter
to your other comment).

https://codereview.chromium.org/2929493003/diff/160001/extensions/renderer/ex...
extensions/renderer/extension_frame_helper.cc:347: DraggableRegion region;
On 2017/06/13 18:38:30, Devlin wrote:
> A minor optimization here would be something like:
> regions.push_back(DraggableRegion());
> DraggableRegion& region = regions.back();
> 
> That way we avoid the copy/assignment.
> 
> Option 2 would be adding move semantics to DraggableRegion, which would also
be
> okay.

Done, although I am not sure if this matters much.  I've done option #1.  It
seems that DraggableRegion is a struct of PODs (bool + 4 ints [nested in
gfx::Rect/Size/Point]) and therefore should be automatically movable (i.e. the
default move constructor/assignment should be reasonable;  or in other words -
it is hard to see how a move [discarding the old value] could be more efficient
than a copy).

[commit-bot: I haz the power, 2017-06-13 23:00:09]

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

[commit-bot: I haz the power, 2017-06-13 23:00:10]

Dry run: This issue passed the CQ dry run.

[Łukasz Anforowicz, 2017-06-13 23:01:57]

The CQ bit was checked by lukasza@chromium.org

[Łukasz Anforowicz, 2017-06-13 23:01:57]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org,
alexmos@chromium.org, rdevlin.cronin@chromium.org
Link to the patchset: https://codereview.chromium.org/2929493003/#ps180001
(title: "Addressed CR feedback from rdevlin.cronin@.")

[commit-bot: I haz the power, 2017-06-13 23:02:26]

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, 2017-06-13 23:09:31]

CQ is committing da patch.

Bot data: {"patchset_id": 180001, "attempt_start_ts": 1497394917086430,
"parent_rev": "bc3c128e15e218688cd067a17e5966fce4364ec1", "commit_rev":
"060c739be2660ac6903b8af1d1585d7eac6bfe25"}

[commit-bot: I haz the power, 2017-06-13 23:09:43]

Description was changed from

==========
Move handling of DraggableRegionsChanged notification from "view" to "frame".

This CL:
- Moves AnnotatedRegionsChanged method from blink::ChromeClient to
  blink::LocalFrameClient
- Moves DraggableRegionsChanged method from blink::WebViewClient to
  blink::WebFrameClient
- Move DraggableRegionsChanged method from content::RenderViewObserver
  to content::RenderFrameObserver
- Moves handling of DraggableRegionsChanged from
  extensions::ExtensionHelper (a content::RenderViewObserver) to
  extensions::ExtensionFrameHelper (a content::RenderFrameObserver).
- Tweaks AppWindowContentsImpl::OnMessageReceived so that it is aware
  which RenderFrameHost sent the ExtensionHostMsg_UpdateDraggableRegions
  IPC.

These changes mean that the originating local frame is no longer lost in
the middle of the notification chain (and that hopefully/speculatively
we will no longer crash by trying to look into a wrong, remote frame
as observed in bug https://crbug.com/645472).

BUG=645472
==========

to

==========
Move handling of DraggableRegionsChanged notification from "view" to "frame".

This CL:
- Moves AnnotatedRegionsChanged method from blink::ChromeClient to
  blink::LocalFrameClient
- Moves DraggableRegionsChanged method from blink::WebViewClient to
  blink::WebFrameClient
- Move DraggableRegionsChanged method from content::RenderViewObserver
  to content::RenderFrameObserver
- Moves handling of DraggableRegionsChanged from
  extensions::ExtensionHelper (a content::RenderViewObserver) to
  extensions::ExtensionFrameHelper (a content::RenderFrameObserver).
- Tweaks AppWindowContentsImpl::OnMessageReceived so that it is aware
  which RenderFrameHost sent the ExtensionHostMsg_UpdateDraggableRegions
  IPC.

These changes mean that the originating local frame is no longer lost in
the middle of the notification chain (and that hopefully/speculatively
we will no longer crash by trying to look into a wrong, remote frame
as observed in bug https://crbug.com/645472).

BUG=645472

Review-Url: https://codereview.chromium.org/2929493003
Cr-Commit-Position: refs/heads/master@{#479195}
Committed:
https://chromium.googlesource.com/chromium/src/+/060c739be2660ac6903b8af1d158...
==========

[commit-bot: I haz the power, 2017-06-13 23:09:45]

Committed patchset #9 (id:180001) as
https://chromium.googlesource.com/chromium/src/+/060c739be2660ac6903b8af1d158...