diff options
| author | twiz@chromium.org <twiz@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-02-10 22:46:47 +0000 |
|---|---|---|
| committer | twiz@chromium.org <twiz@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-02-10 22:46:47 +0000 |
| commit | 2db27be7dbb16f02587b90f150a843d8ad234563 (patch) | |
| tree | 9bfd5b6b2ff4637a69744ce35249361d1f3ea353 /chrome/browser/renderer_host/render_widget_host_view_mac.h | |
| parent | e1ce144bd04336891bb12b967095e938ed5f1bbb (diff) | |
| download | chromium_src-2db27be7dbb16f02587b90f150a843d8ad234563.zip chromium_src-2db27be7dbb16f02587b90f150a843d8ad234563.tar.gz chromium_src-2db27be7dbb16f02587b90f150a843d8ad234563.tar.bz2 | |
CL implementing focus-dismissal of the chrome.experimental.popup set of extension APIs.
Specifically, these changes cause a displayed pop-up to be dismissed when the focus shifts away from both the pop-up view, and the extension-view that launched the pop-up.I had to do a lot of investigating and trial-and-error to converge to the solution present here. I was hoping to be able to piggy-back on the existing FocusManager's various listener routines, but because the pop-up is hosted in a BubbleWidget, which is a separate top-level window with its own focus manager, I could not rely on a given focus manager to take care of the focus change notifications. To get around the above issue, I added a new type of focus listener that can listen on native-window focus change events. I added invocations to this listener throughout the Widget classes in the system so that registered listeners will be notified on focus change.
I found some of the focus change events problematic, as the system will arbitrarily reassign the focus to the main browser window when shifting activation between chrome windows. (SeefocusManagerWin::ClearNativeFocus). To prevent this focus bounce from confusing focus listeners, I added a means to suppress notification of focus change during these operations.
I added GTK and Mac stubs for the new widget functions that will assert when called. GTK and Cocoa development is not my expertise, so I thought // TODO(port) would be wiser.I'm uncertain of the best means to unit-test these changes. Direction in this regard would be appreciated.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/552167
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38685 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/renderer_host/render_widget_host_view_mac.h')
| -rw-r--r-- | chrome/browser/renderer_host/render_widget_host_view_mac.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/chrome/browser/renderer_host/render_widget_host_view_mac.h b/chrome/browser/renderer_host/render_widget_host_view_mac.h index c707205..34903f0 100644 --- a/chrome/browser/renderer_host/render_widget_host_view_mac.h +++ b/chrome/browser/renderer_host/render_widget_host_view_mac.h @@ -115,6 +115,7 @@ class RenderWidgetHostViewMac : public RenderWidgetHostView { virtual void SetWindowVisibility(bool visible); virtual void WindowFrameChanged(); virtual void SetBackground(const SkBitmap& background); + virtual bool ContainsNativeView(gfx::NativeView native_view) const; // Methods associated with GPU plugin instances virtual gfx::PluginWindowHandle AllocateFakePluginWindowHandle(); |
