Expose whether a frame is focused to the browser process

content/browser/renderer_host/render_widget_host_impl.cc

Index: content/browser/renderer_host/render_widget_host_impl.cc
diff --git a/content/browser/renderer_host/render_widget_host_impl.cc b/content/browser/renderer_host/render_widget_host_impl.cc
index 2d695c3d0d42b804dcc5c9295ac012a97d1f70dd..a1d43b8ad8e6abfccfdcd90c182c90e035142d33 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -184,6 +184,7 @@ RenderWidgetHostImpl::RenderWidgetHostImpl(RenderWidgetHostDelegate* delegate,
       allow_privileged_mouse_lock_(false),
       has_touch_handler_(false),
       next_browser_snapshot_id_(1),
+      is_focused_(false),
       weak_factory_(this) {
   CHECK(delegate_);
   if (routing_id_ == MSG_ROUTING_NONE) {
@@ -650,10 +651,13 @@ void RenderWidgetHostImpl::GotFocus() {
 }
 
 void RenderWidgetHostImpl::Focus() {
+  is_focused_ = true;
   Send(new InputMsg_SetFocus(routing_id_, true));
 }
 
 void RenderWidgetHostImpl::Blur() {
+  is_focused_ = false;

[Charlie Reis, 2015/01/21 17:55:33]

Is this always called when another widget grabs focus, even when it's in the
renderer process?  I'm not sure if it's safe to maintain a focus state here.

[mlamouri (slow - plz ping), 2015/01/21 21:33:27]

As far as I can tell, yes. I also did a couple of tests with window.open().
Though, I might have missed some edge cases.

+
   // If there is a pending mouse lock request, we don't want to reject it at
   // this point. The user can switch focus back to this view and approve the
   // request later.
@@ -666,6 +670,10 @@ void RenderWidgetHostImpl::Blur() {
   Send(new InputMsg_SetFocus(routing_id_, false));
 }
 
+bool RenderWidgetHostImpl::IsFocused() const {
+  return is_focused_;
+}
+
 void RenderWidgetHostImpl::LostCapture() {
   if (touch_emulator_)
     touch_emulator_->CancelTouch();