From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010531 BuildID: 2001053120 The Dropdown history list for the url bar is blank Reproducible: Always Steps to Reproduce: 1. Open up Mozilla 2. Type in a URL 3. Observe that the dropdown that appears is blank Actual Results: URL bar drop down history is blank... Expected Results: URL drop down should contain history This could be related to hyatt's style checkin, this occured between the morning build at 11:00 and 11:49PM build at night...

CC'ing hyatt to see if this is related to his STYLE checking

I changed the severity to normal, Reproducible should be "Sometimes" because upon talking to people on irc with windows nobody else seems to be seeing this bug..

Confirmed on win32 build 2001053120 running Win98SE.

Seeing this on Mac on a trunk build from today. I'm also seeing JavaScript errors in the console: Javascript error: chrome://global/content/autocomplete.xml#autocomplete-outlinerbody.getHoverCell() line 1: this.textbox has no properties

Is this about the history dropdown in URL bar (reached by clicking the down-arrow to the right in URL-bar) - or is it the "autocomplete" dropdown that drops down when typing? The history dropdown is fine on linux. The autocomplete is blank. (moz CVS, gcc2.96-81 RH7.1) Opening another window seems to cure the problem. But in the original window autocomplete remains without URL entries.

*** Bug 83636 has been marked as a duplicate of this bug. ***

*** Bug 83823 has been marked as a duplicate of this bug. ***

This is 100% reproducible on 2001-05-31-22 Linux PPC nightly. In the first window, the autocomplete drop-down widget appears but is blank. In subsequent windows, the widget draws text in the expected way.

I'm seeing this javascript-errors too. (Win2k; Build 2001-06-01-20) They appear if the mousecursor is on a empty autocomplete-entry.

Don't know why no one's done this yet, but i think it's obvious that this should be a 0.9.1 stopper. Being that it affects the first window and it'll be the user's first impression of the product. I'd also recommend up-ing the severity to critical or major because it seems to be 100% reproducible on many platforms so . . . nominating for 0.9.1 with severity critical

Nominating, noting regression. Does anyone else think that this broke when the fix went in for the blank autocomplete in windows 2..n?

*** Bug 83903 has been marked as a duplicate of this bug. ***

100% reproduceable on Win98 build 2001060220, my experience is the same as Jeffrey Baker's.

this didnt break because of the fix for 78771, this broke sometime on 5/31, I'm keeping this severity at Normal because there is an easy workaround to this which is to open another window...

over to hewitt, nominating nsbeta1, and setting milestone to get the attention of the triagers.. this is bad!

do we know if this happens on the branch? if not, it's not a beta-stopper.

Hold on a sec... this regressed when Hyatt landed his style changes, AFTER the branch. So this is not a 0.9.1/beta stopper.

Should this go to hyatt?

*** Bug 84107 has been marked as a duplicate of this bug. ***

I'm seeing this on linux too, but not just on the first window. Sometimes a new window will come with a working autocomplete, but usually not.

I am experiencing this as well, using the nightly from 6-5 and 6-6 under FreeBSD 4.3. First window's autocomplete is broken; but subsequent windows have it enabled correctly.

*** Bug 84421 has been marked as a duplicate of this bug. ***

I've traced this down to an XBL problem. The constructor on the binding at chrome://navigator/content/urlbarBindings.#autocomplete-result-popup is not firing, which causes the popup to never get initialized. This binding is used only in navigator, and it extends the base autocomplete binding. The base binding seems to work correctly (in mailnews, open location, nav prefs). So, apparently the fact that I'm extending one binding with another causes the constructors for both bindings to not fire. Hyatt, any ideas?

I have just installed 0.9.1 on linux and i got autocomplete working on the first window (just tested once)

This bug is only present on the main trunk, it was only introduced after 0.9.1 branched.

I dont really know the terms of main or branches. I just know that night releases from may 31 to june 6 had this bug, and 2001060713 (0.9.1) does not

Trunk Win32 build 2001060804 stiil has this bug, as expected on Ari's comment

Themes Triage: Leaving as 0.9.2, this is a high number of users, high frequency problem that we need to fix for rtm. P2

PDT has approved this bug for 0.9.2

*** Bug 85091 has been marked as a duplicate of this bug. ***

I'm seeing this on more than just the first window. When closing windows do we recycle them? that might explain it. For example if I open four windows, then close the first and open a fifth, it also has this problem.

*** Bug 85126 has been marked as a duplicate of this bug. ***

If autocomplete worked before on the second window with no such binding (as provided by the patch), then why should we need this? What's different about the first and second window? Do we have an underlying problem with binding attachment order or CSS async loading that this patch is sweeping under the carpet?

The constructor on the binding for the popup was not firing, apparently because the tree of bindings were loading asynchronously and were not there at the right time. Forcing the correct display type on this popup seems to result in the bindings loading earlier.

*** Bug 85274 has been marked as a duplicate of this bug. ***

hyatt explained all that is going on. i like it. r=pink.

Opening a second window makes no difference to me, I still get a blank autocomplete window. Win98 2001061204

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

fixed

can't bugzilla read my mind and change the resolution when I say "fixed"?

*** Bug 85611 has been marked as a duplicate of this bug. ***

I can not confirm this fixed in 2001061305 trunk for Mac. It is still blank.

It works fine both on Win32 2001061309 build and on CVS tree build with WindowsME.

*** Bug 85728 has been marked as a duplicate of this bug. ***

I am still seeing the problem on 2001061208 on Linux.

Works for me Win2k 2001061304

It works on Linux with build 2001061309

*** Bug 85790 has been marked as a duplicate of this bug. ***

This is still not quite right. In 6/14 builds on mac/win32/linux, I get a blank popup when I begin to type in the urlbar after starting up mozilla. But, once I hit the first match successfully, after that, I never get a blank popup. Steps: 1) start mozilla and create a new profile 2) when browser has started, begin to type 'www.mozilla.org' in the urlbar 3) as soon as you type 'ww' a blank popup appears (plus 'Search' below it) 4) backspace twice, type 'ww': blank popup comes back 5) completely type www.mozilla.org and hit enter, so it's now an available match 6) type 'ww': blank popup 7) type 'www.m': popup now offers the one available match, www.mozilla.org 8) backspace and type 'ww': no blank popup (just 'Search' line) 9) type 'www.m': popup again offers the one available match. (Side note: on Mac, the 'Search' line is not showing up, just a thin grey line which is barely visible).

Shouldn't that be a different bug ? The First Autocomplete bug doesnt appear anymore so I dont see any reason why this should be reopened. It may be a consequence of this checking, but this bug doesnt appear anymore...

Er, well, this is what I see: > Steps to Reproduce: > 1. Open up Mozilla > 2. Type in a URL > 3. Observe that the dropdown that appears is blank That's /not/ this bug? (Not really arguing, just confused).

Adding mostfreq at 11 bugs

The difference is there was no way to get the autocomplete dropdown results to appear unless a second windows was opened, this however envolves a slight difference in that in involves backspacing and re-entering and pressing enter and such to fix it. Does this happen in a second window as well when nothing is done to the first window ?

Well, in the first window that I open, when I begin typing, "the first instance of autocomplete is blank". When a match is found, it fills with text. After a match is found, it never comes up blank again.

ummm... John could you open a new bug? Because this bug was about autocomplete not working at all in the first instance of a browser window. I've seen what you are describing even in the second or third instance of a browser window (not very sure about this, but I've might have seen the same effect before this bug appeared). Another thing to check is if it might be related to the fix (see Joe Hewitt's 2001-06-07 17:50 comment and onward). At any rate, I recommend opening a new bug as this bug is fixed.

.

un peu de retard!

VERIFIED Fixed with 2001062104 builds. jOhn is your bug written up anywhere? I think I saw it, but it would be good to cite it here.

Sure, cLaUdIu5. Bug 86551.

The last few nightlies have been doing this again...

I don't see anything like this in the 1.2 branch or trunk linux nightlies. WFM?

The same (or very similar) problem happens to me running 1.5a+ on Win98SE, no problem with 1.4 or older. When typing address, the dropdown menu that appears is clear (but the size of the menu is right, just seem like "white font on white background"), when pressing the "down" button, the addresses from history reappear. Doesn't occur on newly opened windows, or when clicking the arrow next to location bar. I don't know when this appears, sometimes it just goes away...

Yes, just what Juro said: sometimes autocomplete list is blank, pressing "down arrow" shows list back. Linux 20030810 nightly build here. As several bugs describing exactly the same symptoms were duped to this one (bug 85611, bug 85790), I think its the right place to report.

this is FIXED. what jrgm described in comment 50 is bug 261362