Comment #3 on issue 6987 by tvamsikalyan: Clicking anywhere else should
close the AutocompletePopup
http://code.google.com/p/chromium/issues/detail?id=6987
I noticed that when AutocompletePopup is visible, minimizing the browser and
then maximizing it back will still show the popup window. I feel the
solution should
work for all possibilities (clicking on menus, title bar, session history
etc) that
we know today, and as well as for any future possibilities.
--------------------------
I thought following sequence would work fine, and it will use
FocusManager's logic
to call OnKillFocus on AutocompletePopup.
HWND hWnd = ::SetFocus(NULL);
menu activate;
::SetFocus(hWnd)
The disadvantage here is we need to be aware of list of places where we need
to handle AutocompletePopup.
--------------------------
One more approach that I could think of is understanding how TrackPopMenu
Windows
API works (Wine must have already implemented it). But as I see IE and
Firefox
certainly do not implement it that way, because when menu is open cursor
style does
not change depending on content below it.
--------------------------
The better solution that I personally vote for is the following.
MessagePumpForUI::ProcessMessageHelper, which receives all messages calls
WillProcessMessage(msg) on registered observers. For example Jankometer uses
JancoObserver. Similar to it, we can register one observer with following
code
in its WillProcessMessage(msg)
void WillProcessMessage(const MSG& msg) {
switch(msg.message)
{
case WM_LBUTTONDOWN:
case WM_LBUTTONUP:
case WM_RBUTTONDOWN:
case WM_RBUTTONUP:
case WM_LBUTTONDBLCLK:
case WM_RBUTTONDBLCLK:
case WM_MBUTTONDBLCLK:
case WM_MBUTTONDOWN:
case WM_MBUTTONUP:
case WM_MOUSEHWHEEL:
{
if(view_->GetHWnd() != msg.hwnd)
view_->GetModel()->StopAutocomplete();
}
default:
break;
}
}
and register and unregister observer from StartAutoComplete and
StopAutoComplete.
The observer verifies for mouse events only till the popup is visible.
Advantages
are that little or no performance overhead and it will fix the issue once
for all.
Disadvantage is that such observer needs to know the HWND of the popup
view, and we
need to somehow initialize observer with NativeView by reading it from a
class that
is derived from AutocompletePopupView. I am not sure how it can work across
different
platforms.
--------------------------
Please suggest whether above observer approach will be fine or not. If not
please
mention how else I can approach.
I need to coordinate with you in case you want me to go ahead and implement
fix for
it.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
