Hey Peter, this looks like the same Check we saw in 13500.  The strange part is that 
195 was branch after the change in there was fixed.  Could you take a look?

Note: My fix in r20395 went in to 3.0.193.1 and later.

This stack also appears in 3.0.195.6, 3.0.195.1, and 3.0.193.2; I can't find it in 3.0.193.1.

The following two stacks also occur in 3.0.195.10, 3.0.195.6, 3.0.195.1, 3.0.193.2, 3.0.193.1, 3.0.193.0:

0x01fea448	 [chrome.dll	 - logging.cc:553]	 logging::LogMessage::~LogMessage()
0x0216a3ef	 [chrome.dll	 - autocomplete_popup_model.cc:175]	 AutocompletePopupModel::URLsForCurrentSelection(unsigned int 
*,bool *,GURL *)
0x0211d29f	 [chrome.dll	 - autocomplete_edit.cc:561]	 AutocompleteEditModel::GetURLForCurrentText(unsigned int *,bool 
*,GURL *)
0x0211c61a	 [chrome.dll	 - autocomplete_edit.cc:150]	 AutocompleteEditModel::CurrentTextIsURL()
0x020f830e	 [chrome.dll	 - go_button.cc:122]	 
GoButton::GetTooltipText(int,int,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > *)
0x0227c05c	 [chrome.dll	 - tooltip_manager_win.cc:350]	 views::TooltipManagerWin::UpdateTooltip(int,int)
0x0227c134	 [chrome.dll	 - tooltip_manager_win.cc:377]	 views::TooltipManagerWin::OnMouse(unsigned int,unsigned int,long)
0x02271dc0	 [chrome.dll	 - widget_win.cc:675]	 views::WidgetWin::OnMouseRange(unsigned int,unsigned int,long)
0x022705d3	 [chrome.dll	 - widget_win.h:129]	 views::WidgetWin::_ProcessWindowMessage(HWND__ *,unsigned int,unsigned 
int,long,long &,unsigned long)
0x02272668	 [chrome.dll	 - widget_win.cc:1067]	 views::WidgetWin::WndProc(HWND__ *,unsigned int,unsigned int,long)


0x5925a448	 [chrome.dll	 - logging.cc:553]	 logging::LogMessage::~LogMessage()
0x593da3ef	 [chrome.dll	 - autocomplete_popup_model.cc:175]	 AutocompletePopupModel::URLsForCurrentSelection(unsigned int 
*,bool *,GURL *)
0x5938d29f	 [chrome.dll	 - autocomplete_edit.cc:561]	 AutocompleteEditModel::GetURLForCurrentText(unsigned int *,bool 
*,GURL *)
0x5938c9e9	 [chrome.dll	 - autocomplete_edit.cc:260]	 AutocompleteEditModel::AcceptInput(WindowOpenDisposition,bool)
0x593ee4e4	 [chrome.dll	 - autocomplete_edit_view_win.cc:1725]	 
AutocompleteEditViewWin::OnKeyDownOnlyWritable(wchar_t,unsigned int,unsigned int)
0x593edb30	 [chrome.dll	 - autocomplete_edit_view_win.cc:1291]	 AutocompleteEditViewWin::OnKeyDown(wchar_t,unsigned 
int,unsigned int)
0x593ebc1d	 [chrome.dll	 - autocomplete_edit_view_win.h:159]	 AutocompleteEditViewWin::ProcessWindowMessage(HWND__ 
*,unsigned int,unsigned int,long,long &,unsigned long)


The following stack occurs in 3.0.193.1:

0x01fea448	 [chrome.dll	 - logging.cc:553]	 logging::LogMessage::~LogMessage()
0x0216a3ef	 [chrome.dll	 - autocomplete_popup_model.cc:175]	 AutocompletePopupModel::URLsForCurrentSelection(unsigned int 
*,bool *,GURL *)
0x0211d29f	 [chrome.dll	 - autocomplete_edit.cc:561]	 AutocompleteEditModel::GetURLForCurrentText(unsigned int *,bool 
*,GURL *)
0x0211c61a	 [chrome.dll	 - autocomplete_edit.cc:150]	 AutocompleteEditModel::CurrentTextIsURL()
0x0217eb3e	 [chrome.dll	 - autocomplete_edit_view_win.cc:2002]	 AutocompleteEditViewWin::EmphasizeURLComponents()
0x0217f15e	 [chrome.dll	 - autocomplete_edit_view_win.cc:2171]	 AutocompleteEditViewWin::TextChanged()
0x0217cc89	 [chrome.dll	 - autocomplete_edit_view_win.cc:624]	 
AutocompleteEditViewWin::SetUserText(std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const 
&,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > const &,bool)
0x0211c4a6	 [chrome.dll	 - autocomplete_edit.cc:101]	 AutocompleteEditModel::RestoreState(AutocompleteEditModel::State 
const &)
0x0217cabe	 [chrome.dll	 - autocomplete_edit_view_win.cc:551]	 AutocompleteEditViewWin::Update(TabContents const *)
0x0214c04e	 [chrome.dll	 - location_bar_view.cc:234]	 LocationBarView::Update(TabContents const *)
0x0206278f	 [chrome.dll	 - browser_view.cc:785]	 BrowserView::UpdateToolbar(TabContents *,bool)
0x02075a37	 [chrome.dll	 - browser.cc:2255]	 Browser::UpdateToolbar(bool)
0x020749dd	 [chrome.dll	 - browser.cc:1638]	 Browser::TabSelectedAt(TabContents *,TabContents *,int,bool)
0x0209d8b7	 [chrome.dll	 - tab_strip_model.cc:657]	 TabStripModel::ChangeSelectedContentsFrom(TabContents *,int,bool)
0x0209ca57	 [chrome.dll	 - tab_strip_model.cc:147]	 TabStripModel::DetachTabContentsAt(int)
0x0209d528	 [chrome.dll	 - tab_strip_model.cc:554]	 TabStripModel::Observe(NotificationType,NotificationSource const 
&,NotificationDetails const &)
0x0219dd4a	 [chrome.dll	 - notification_service.cc:107]	 NotificationService::Notify(NotificationType,NotificationSource 
const &,NotificationDetails const &)
0x0206b940	 [chrome.dll	 - tab_contents.cc:333]	 TabContents::~TabContents()

 Issue 15591  has been merged into this issue.

 Issue 17024  has been merged into this issue.

According to the duped bugs, this affects both XP and Vista, and has been present 
since at least build 189 (which is probably around when I added this CHECK).

The stacks indicate that the popup is open, the controller is done, and the 
controller |result_| is empty.  I don't see how this can be true.  Note that r20395 
fixed a case in which we were mutating the results inside the callstack; stacks like 
the first one in comment 2 don't have any room for that to happen.

I have tried playing around a bit with Japanese, Korean and Chinese IMEs on my fista 
box, and with rapidly typing & hitting <esc> while moving the mouse on the go button.  
I haven't been able to repro so far.

CCing the people who know anything about omnibox code.  This one has me stumped :(

Can you get into this state if there is no default search engine?

Is that state possible?  We don't let users delete their default engine, and the 
prepopulate data ensures that we start with a nonzero number of engines.  I guess if 
a user fiddled with the bits on disk this could happen, but it seems unlikely that 
that would result in a topcrash.

To answer the question directly, I don't think so, but I'm not sure.  If there is no 
default engine there may be no results, but in that case the popup shouldn't ever 
open.

My current idea is to try to (locally) add some code which runs on a rapid timer 
(e.g. 10 ms) and just polls GetURLForCurrentText(), and then run that build and play 
around with it hoping to trip some kind of race condition.  I can't see any places in 
the code that should be races, though...

Updates:

* I tried to repro with no search engines, and failed.
* I tried to repro by adding code that called GetURLForCurrentText() every 10 ms and 
then banging on things, and failed.
* Stacks like these are still present on trunk, even after my recent cleanups (which, 
admittedly, I didn't think would help).  Because the line numbers have changed 
slightly I'll paste some from 4.206 below:


0x67fd49ca	 [chrome.dll	 - logging.cc:557]	 
logging::LogMessage::~LogMessage()
0x6815ead3	 [chrome.dll	 - autocomplete_popup_model.cc:171]	 
AutocompletePopupModel::URLsForCurrentSelection(unsigned int *,bool *,GURL *)
0x680efdee	 [chrome.dll	 - autocomplete_edit.cc:598]	 
AutocompleteEditModel::GetURLForCurrentText(unsigned int *,bool *,GURL *)
0x680ef3cd	 [chrome.dll	 - autocomplete_edit.cc:266]	 
AutocompleteEditModel::AcceptInput(WindowOpenDisposition,bool)
0x681a9760	 [chrome.dll	 - autocomplete_edit_view_win.cc:1736]	 
AutocompleteEditViewWin::OnKeyDownOnlyWritable(wchar_t,unsigned int,unsigned int)
0x681a8dac	 [chrome.dll	 - autocomplete_edit_view_win.cc:1302]	 
AutocompleteEditViewWin::OnKeyDown(wchar_t,unsigned int,unsigned int)


0x020049ca	 [chrome.dll	 - logging.cc:557]	 
logging::LogMessage::~LogMessage()
0x0218ead3	 [chrome.dll	 - autocomplete_popup_model.cc:171]	 
AutocompletePopupModel::URLsForCurrentSelection(unsigned int *,bool *,GURL *)
0x0211fdee	 [chrome.dll	 - autocomplete_edit.cc:598]	 
AutocompleteEditModel::GetURLForCurrentText(unsigned int *,bool *,GURL *)
0x0211effa	 [chrome.dll	 - autocomplete_edit.cc:156]	 
AutocompleteEditModel::CurrentTextIsURL()
0x02150a6d	 [chrome.dll	 - go_button.cc:122]	 
GoButton::GetTooltipText(int,int,std::basic_string<wchar_t,std::char_traits<wchar_t>,
std::allocator<wchar_t> > *)
0x022e9ac1	 [chrome.dll	 - tooltip_manager_win.cc:349]	 
views::TooltipManagerWin::UpdateTooltip(int,int)
0x022e9ba5	 [chrome.dll	 - tooltip_manager_win.cc:377]	 
views::TooltipManagerWin::OnMouse(unsigned int,unsigned int,long)


0x020049ca	 [chrome.dll	 - logging.cc:557]	 
logging::LogMessage::~LogMessage()
0x0218ead3	 [chrome.dll	 - autocomplete_popup_model.cc:171]	 
AutocompletePopupModel::URLsForCurrentSelection(unsigned int *,bool *,GURL *)
0x0211fdee	 [chrome.dll	 - autocomplete_edit.cc:598]	 
AutocompleteEditModel::GetURLForCurrentText(unsigned int *,bool *,GURL *)
0x0211effa	 [chrome.dll	 - autocomplete_edit.cc:156]	 
AutocompleteEditModel::CurrentTextIsURL()
0x021d9dba	 [chrome.dll	 - autocomplete_edit_view_win.cc:2013]	 
AutocompleteEditViewWin::EmphasizeURLComponents()
0x021da3da	 [chrome.dll	 - autocomplete_edit_view_win.cc:2182]	 
AutocompleteEditViewWin::TextChanged()
0x021d854f	 [chrome.dll	 - autocomplete_edit_view_win.cc:873]	 
AutocompleteEditViewWin::OnAfterPossibleChange()
0x021d96af	 [chrome.dll	 - autocomplete_edit_view_win.cc:1720]	 
AutocompleteEditViewWin::HandleKeystroke(unsigned int,wchar_t,unsigned int,unsigned 
int)
0x021d8dc6	 [chrome.dll	 - autocomplete_edit_view_win.cc:1307]	 
AutocompleteEditViewWin::OnKeyDown(wchar_t,unsigned int,unsigned int)

This has been happening since 1.0, I'd still like to see the fix for this pulled into 
3.0, but at this point I'm not going to hold up the 3.0 release.

4.0.206.1 has been in the field for about a week.  We have a lot of crash data 
for it.  This crash is no longer being reported.  It is probable that we can close 
this.

Comment 10 lies utterly; 4.0.206.1 has these same stacks.

This crash is indeed still in trunk.

My apologies, for some reason a query for the entire signature returns no results, 
http://crash/search?
query=product:Chrome+version:4.0.206.1+AutocompletePopupModel::URLsForCurrent
Selection(unsigned+int+*,bool+*,GURL+*)

The top of the stack is "~LogMessage()", not "URLsForCurrentSelection()".  Perhaps 
crash/'s search function will only find that.  Or perhaps it's broken utterly.  I don't 
know, I never use it because it never works for me.

 Issue 21817  has been merged into this issue.

This is currently 4.7% of our browser crashes in the current stable release 3.0.195.21, 
it's second only to sqlite and empty crashers.  Any more thoughts on things we could do 
to tackle this issue?

Why CC Rahul?

The only thing I can think of is to put the current address bar text/selection, and the 
popup size/contents, onto the stack right before crashing, so we can see them in the 
crash reports and see if we can deduce a pattern.

This crash is showing in healthy numbers in 3.0.195.25

reportid=62c44b39a606da2b
reportid=46158e6a597276dc

I guesstimate that is the 6th more common crash but we are still early in the push.

This is probably the top crasher, right now is at third place but the top two buckets 
are mixing several different crashes.

Telling me that doesn't fix the crash or give me any more ideas of how to track it 
down.

I'm pretty stacked with Jank work, and basically haven't thought about this much in the 
last month, after I spent days getting nowhere.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=28348 

------------------------------------------------------------------------
r28348 | pkasting@chromium.org | 2009-10-07 16:44:12 -0700 (Wed, 07 Oct 2009) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.cc?r1=28348&r2=28347

Add another sanity check, this time that the popup's "open state" (HWND) matches its result count (views).

BUG=20511
TEST=none
Review URL: http://codereview.chromium.org/271013
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=28361 

------------------------------------------------------------------------
r28361 | pkasting@chromium.org | 2009-10-07 18:00:03 -0700 (Wed, 07 Oct 2009) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.cc?r1=28361&r2=28360

Revert sanity check; this doesn't actually work since UpdatePopupAppearance() never removes child views (the popup quickly grows to its child limit and then stays there forever; we only show some of the children at a time though).

BUG=20511
TEST=none
TBR=huanr
Review URL: http://codereview.chromium.org/262018
------------------------------------------------------------------------

 Issue 24137  has been merged into this issue.

This crash was found in 4.0.221.6 and is currently ranked #19 (based on the relative number of reports in the release).  There have been 70 reports from 70 clients.

Report Link: http://crash/reportdetail?reportid=609952bbf1d8d54d
http://crash/search?query=Chrome+4.0.221.6+AutocompletePopupModel%3A%3AURLsForCurrentSelection%28unsigned+int+*%2Cbool+*%2CGURL+*%29

@pkasting: I'm intrigued by your mention of Japanese in comment #5. Is there a 
positive correlation with a visit to a CJK page around the time of the crash?

How would I know?  We don't track what sites people visit, and anyway, why would 
visiting some site trigger a crash in the address bar code?

Since this is also happening on ToT, I'm going to move this to 4.0.  If we have a fix 
to back port, it will get priority for 3.0.

Build: 4.0.223.11

I got this crash on my personal laptop (XP/SP3) today morning. 
-Launched chrome (my laptop was little bit slow) before the NNTP is loaded, navigated
to a webpage.
Browser window crashed on me once. 

The full callstack can be found @
http://crash/reportdetail?reportid=68429e96948e97d9#crashing_thread

Can you say precisely what page and how you navigated?  Also what the UI did while you 
were interacting with it (e.g. showed the address bar dropdown, kept up with your 
typing, etc.)?  When did the crash occur?

Basically, I need steps that trigger this, and what the browser acts like when this 
gets triggered.

(No comment was entered for this change.)

It seems we are just collecting crashes but not getting more useful information and 
making progress. Do we still need this CHECK in place? 14% of total browser crashes are 
due to this. If we are not gaining anything from it and have no plan to further 
proceed, can we just gracefully handle empty result?

No, we do not have "no plan to further proceed", and no, we cannot remove this.

@comment29 (sorry for late reply)

-Set NNTP as my home page.
-Launched Chrome
-Before NNTP page is loading, put cursor in Omnibox and typed cnn.com in Omnibox
(selected from Omnibox dropdown list) and hit return key.

That's it, the browser is crashed on me.

I guess the crash happened on Oct 26th @ 8.00 a.m.

"typed cnn.com in Omnibox (selected from Omnibox dropdown list)"

What does this mean?  Does this mean you started to type it and then arrowed down to an 
entry in the dropdown, or clicked one with your mouse?  Do you recall how much you 
typed, whether it inline autocompleted, or how many entries were in the dropdown?

Does this mean you started to type it and then arrowed down to an 
entry in the dropdown, - Yes.

I typed c in the omnibox and selected cnn.com from the nav-suggested drop-down list
and hit return key.

I guess it is not inline autocompleted. 

Thanks.  "cnn.com" isn't a navsuggest result for 'c' in my testing, but it could have 
been in your list due to a previous visit.

Are you able to reproduce by trying your steps again?

Are you able to reproduce by trying your steps again? NO
As I said @comment28, it happened once. Could not be able to reproduce it again. In
case, if I'm luck one more time to reproduce it, I will update the thread.

(No comment was entered for this change.)

Checked the uptime figures on some of the stacks.  The numbers were all over, many very 
long, so this isn't happening due to some startup-specific condition.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=30908 

------------------------------------------------------------------------
r30908 | pkasting@chromium.org | 2009-11-03 17:01:01 -0800 (Tue, 03 Nov 2009) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete.cc?r1=30908&r2=30907
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete_popup_model.cc?r1=30908&r2=30907
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.cc?r1=30908&r2=30907
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.h?r1=30908&r2=30907
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_win.cc?r1=30908&r2=30907
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_win.h?r1=30908&r2=30907

Try to add more sanity checking to help track down a crash.

BUG=20511
TEST=none
Review URL: http://codereview.chromium.org/342112
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31119 

------------------------------------------------------------------------
r31119 | pkasting@chromium.org | 2009-11-05 11:40:26 -0800 (Thu, 05 Nov 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_gtk.cc?r1=31119&r2=31118
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_gtk.h?r1=31119&r2=31118
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_win.cc?r1=31119&r2=31118

Fix checkfailure on Linux Views build by actually opening the popup when it's initted.

Also add sanity checking like in the Windows version.

BUG=20511
TEST=none
Review URL: http://codereview.chromium.org/361020
------------------------------------------------------------------------

(No comment was entered for this change.)

This crash was found in 4.0.223.16 and is currently ranked #8 (based on the relative number of reports in the release).  There have been 82 reports from 78 clients.

Report Link: http://crash/reportdetail?reportid=617604f5317f6763&newsig=
http://crash/search?query=Chrome+4.0.223.16+AutocompletePopupModel%3A%3AURLsForCurrentSelection%28unsigned+int+*%2Cbool+*%2CGURL+*%29

This crash was not found in 4.0.237.0. We last saw it in 4.0.223.16.  Assuming the crash has been fixed, please mark accordingly.

 Issue 27069  has been merged into this issue.

Now the crash happens on this CHECK:

autocomplete_popup_win.cc:63 CHECK(is_open == is_open_);

0x64ead8d7	 [chrome.dll	 - logging.cc:561]	 logging::LogMessage::~LogMessage()
0x650a43f4	 [chrome.dll	 - autocomplete_popup_win.cc:63]	 AutocompletePopupWin::IsOpen()
0x6509ff36	 [chrome.dll	 - autocomplete_popup_contents_view.cc:623]	 AutocompletePopupContentsView::IsOpen()
0x650a037e	 [chrome.dll	 - autocomplete_popup_contents_view.cc:746]	 AutocompletePopupContentsView::AnimationProgressed(Animation const *)
0x65520709	 [chrome.dll	 - animation.cc:107]	 Animation::Step()
0x64f09a92	 [chrome.dll	 - timer.h:159]	 base::BaseTimer<BookmarkDropInfo,1>::TimerTask::Run()

Excellent!  That narrows the issue down considerably.

adding label for Henry's report.

I have a repro for this.

Type a character in the address bar, hit the minimize button, click the taskbar entry 
to restore the window, hover the Go button.

The problem is that Windows hides the popup window (for minimizing) directly, then 
the edit tries to close it (which is implemented as a second hide).  Then on restore 
Windows shows the window, and the state becomes inconsistent.

There are a number of ways to attack this.  Probably the simplest is to truly close 
the window instead of just hiding it, which will prevent Windows from restoring it.  
I'm not sure why we aren't doing that currently.

Fixed in r31649.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31649 

------------------------------------------------------------------------
r31649 | pkasting@chromium.org | 2009-11-10 21:42:41 -0800 (Tue, 10 Nov 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete_popup_model.cc?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.cc?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.h?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_gtk.cc?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_gtk.h?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_win.cc?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_win.h?r1=31649&r2=31648

Avoid inconsistent state (leading to checkfailures) due to Windows minimize/restore functionality hiding and showing the autocomplete dropdown outside of the awareness of the controller.

Instead, this switches to the simpler model of just creating a new HWND when we want to show the dropdown, and destroying it when we want to close it.  Happily, this also seems to save quite a bit of code.

BUG=20511
TEST=Type a character in the omnibox, minimize the window, and restore it.  The dropdown should have disappeared.
Review URL: http://codereview.chromium.org/391011
------------------------------------------------------------------------

Woohoo! Go pkasting@ !!!

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31694 

------------------------------------------------------------------------
r31694 | pkasting@chromium.org | 2009-11-11 12:07:39 -0800 (Wed, 11 Nov 2009) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/195/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.cc?r1=31694&r2=31693
   M http://src.chromium.org/viewvc/chrome/branches/195/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.h?r1=31694&r2=31693
   M http://src.chromium.org/viewvc/chrome/branches/195/src/chrome/browser/views/autocomplete/autocomplete_popup_win.cc?r1=31694&r2=31693
   M http://src.chromium.org/viewvc/chrome/branches/195/src/chrome/browser/views/autocomplete/autocomplete_popup_win.h?r1=31694&r2=31693

Merge crash fix to 3.0.

BUG=20511
TEST=Type a character in the omnibox, minimize the window, and restore it.  The dropdown should have disappeared.
Review URL: http://codereview.chromium.org/385041
------------------------------------------------------------------------

 Issue 27209  has been merged into this issue.

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31649 

------------------------------------------------------------------------
r31649 | pkasting@chromium.org | 2009-11-10 21:42:41 -0800 (Tue, 10 Nov 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete_popup_model.cc?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.cc?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.h?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_gtk.cc?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_gtk.h?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_win.cc?r1=31649&r2=31648
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/autocomplete/autocomplete_popup_win.h?r1=31649&r2=31648

Avoid inconsistent state (leading to checkfailures) due to Windows minimize/restore functionality hiding and showing the autocomplete dropdown outside of the awareness of the controller.

Instead, this switches to the simpler model of just creating a new HWND when we want to show the dropdown, and destroying it when we want to close it.  Happily, this also seems to save quite a bit of code.

BUG=20511
TEST=Type a character in the omnibox, minimize the window, and restore it.  The dropdown should have disappeared.
Review URL: http://codereview.chromium.org/391011
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=31694 

------------------------------------------------------------------------
r31694 | pkasting@chromium.org | 2009-11-11 12:07:39 -0800 (Wed, 11 Nov 2009) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/195/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.cc?r1=31694&r2=31693
   M http://src.chromium.org/viewvc/chrome/branches/195/src/chrome/browser/views/autocomplete/autocomplete_popup_contents_view.h?r1=31694&r2=31693
   M http://src.chromium.org/viewvc/chrome/branches/195/src/chrome/browser/views/autocomplete/autocomplete_popup_win.cc?r1=31694&r2=31693
   M http://src.chromium.org/viewvc/chrome/branches/195/src/chrome/browser/views/autocomplete/autocomplete_popup_win.h?r1=31694&r2=31693

Merge crash fix to 3.0.

BUG=20511
TEST=Type a character in the omnibox, minimize the window, and restore it.  The dropdown should have disappeared.
Review URL: http://codereview.chromium.org/385041
------------------------------------------------------------------------

@comment7&8:
Yes, It is possoble to have a empty search engines list. Pls refer to
 Issue 2714 :  Don't allow the user to have empty search engine list  

Just reproduced the empty search engines list with 3.0.195.38 and screenshot 
attached.

	2714.PNG 24.1 KB   View   Download

Build: 3.0.195.38 (Official Build 34131)