Move has_focus_ tracking from RenderWidget to RenderView.

content/renderer/render_widget.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/render_widget.h"
 
 #include "base/auto_reset.h"
 #include "base/bind.h"
 #include "base/command_line.h"
 #include "base/debug/dump_without_crashing.h"
@@ skipping 478 matching lines @@
       top_controls_shrink_blink_size_(false),
       top_controls_height_(0.f),
       next_paint_flags_(0),
       auto_resize_mode_(false),
       need_update_rect_for_auto_resize_(false),
       did_show_(false),
       is_hidden_(hidden),
       compositor_never_visible_(never_visible),
       is_fullscreen_granted_(false),
       display_mode_(blink::WebDisplayModeUndefined),
-      has_focus_(false),
       handling_input_event_(false),
       handling_event_overscroll_(nullptr),
       handling_ime_event_(false),
       handling_event_type_(WebInputEvent::Undefined),
       ignore_ack_for_mouse_move_from_debugger_(false),
       closing_(false),
       host_closing_(false),
       is_swapped_out_(swapped_out),
       for_oopif_(false),
       text_input_type_(ui::TEXT_INPUT_TYPE_NONE),
@@ skipping 776 matching lines @@
   if (webwidget_)
     webwidget_->setCursorVisibilityState(is_visible);
 }
 
 void RenderWidget::OnMouseCaptureLost() {
   if (webwidget_)
     webwidget_->mouseCaptureLost();
 }
 
 void RenderWidget::OnSetFocus(bool enable) {
-  has_focus_ = enable;
-
   // TODO(nasko): This code is here to help diagnose https://crbug.com/541578.
   if (webwidget_->isWebView()) {
     blink::WebView* view = static_cast<blink::WebView*>(webwidget_);
     if (view->mainFrame()->isWebRemoteFrame()) {
       blink::WebFrame* mainFrame = view->mainFrame();
 
       base::debug::Alias(&mainFrame);
       base::debug::Alias(&is_swapped_out_);
 
       base::debug::DumpWithoutCrashing();
     }
   }
 
   if (webwidget_)
     webwidget_->setFocus(enable);

[Charlie Reis, 2015/10/14 19:32:52]

Daniel/Ken, can I get a sanity check here?  content/ will now track page-level
focus on the view rather than the widget, since there could be more than one
widget in the page.

This call shows that Blink is still tracking (presumably) page-level focus at
the widget level.  Is that sane?  What happens if there are multiple widgets?

[alexmos, 2015/10/14 20:12:33]

Yes, it'd be good to have Daniel or Ken double-check this.  IIUC, Blink doesn't
track this at the widget level but rather at Page level, and all the widget
implementations that handle this proceed to forward it to blink::Page's
FocusController.  If there are multiple widgets due to --site-per-process,
currently only the top one gets this message (that's why we don't have
page-level focus set correctly in subframe processes).

It might be good to eventually remove page-level focus tracking from
FocusController and get it from the embedder instead (i.e., from has_focus_), so
that the two can't become inconsistent.

[kenrb, 2015/10/15 18:57:30]

It looks like setFocus() could move from from WebWidget to WebView, since indeed
it does simply access the Page from there. It could be cleaner, and would let us
remove the currently duplicated code between WebViewImpl and WebFrameWidget, but
I don't actually know if there is any functional improvement.

Alex, what do you mean by "currently on the top one get the message"? It looks
to me like it wouldn't even matter which WebWidget is used for the setFocus()
call, since it doesn't access any WebWidget members other than what it needs to
access the Page. FocusController should know which Frame has focus regardless of
which WebWidget it is under.

[alexmos, 2015/10/15 20:29:30]

I think this would be good to do.  It seems that WebFrameWidget's implementation
is actually an imcomplete copy (it doesn't deal with blur), so this would fix
that.  But how would we deal with the WebPagePopupImpl::setFocus, which is the
other implementation?
Right.  I was just pointing out that subframe WebWidgets never actually receive
that message today, since the browser process only sends it for the top frame's
WebWidget, but I agree that it wouldn't matter even if they did.

[kenrb, 2015/10/16 20:38:16]

That's a good point, and probably a reason to leave it on WebWidget.

 }
 
 void RenderWidget::FlushPendingInputEventAck() {
   if (pending_input_event_ack_) {
     TRACE_EVENT_ASYNC_END0("input", "RenderWidget::ThrottledInputEventAck",
                            pending_input_event_ack_.get());
     Send(pending_input_event_ack_.release());
   }
   total_input_handling_time_this_frame_ = base::TimeDelta();
 }
@@ skipping 1077 matching lines @@
 void RenderWidget::RegisterVideoHoleFrame(RenderFrameImpl* frame) {
   video_hole_frames_.AddObserver(frame);
 }
 
 void RenderWidget::UnregisterVideoHoleFrame(RenderFrameImpl* frame) {
   video_hole_frames_.RemoveObserver(frame);
 }
 #endif  // defined(VIDEO_HOLE)
 
 }  // namespace content