Closed Bug 83632 Opened 23 years ago Closed 19 years ago

First instance of autocomplete is blank

Categories

(SeaMonkey :: Location Bar, defect, P2)

Product:
SeaMonkey
Component:
Location Bar
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: scttran, Assigned: hewitt)

References

Details

(Keywords: regression)

Attachments

(1 file)

patch to fix (from hyatt)
540 bytes, patch
Details | Diff | Splinter Review 
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
Summary: URL Bar will dot display and history → URL Bar will not display and history
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..
Severity: major → normal
Summary: URL Bar will not display and history → URL Bar will not display history
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
OS: Windows 2000 → All
Hardware: PC → All
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. ***
Summary: URL Bar will not display history → First instance of autocomplete is blank
*** 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?
Keywords: mozilla0.9.1, regression
*** 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.
Whiteboard: 0.9.1
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!
Assignee: alecf → hewitt
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
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.
Keywords: mozilla0.9.1, nsbeta1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Status: NEW → ASSIGNED
Should this go to hyatt?
Keywords: mozilla0.9.2, nsCatFood
*** 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?
Whiteboard: 0.9.1
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
Priority: -- → 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"?
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → 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).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
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
Keywords: mostfreq

    
    

    
  
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.

    
    

    
  
.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Summary: First instance of autocomplete is blank

    
    

    
  
un peu de retard!
Summary: First instance of autocomplete is blank

    
    

    
  
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.

Status: RESOLVED → VERIFIED

    
    

    
  
Sure, cLaUdIu5. Bug 86551.

    
    

    
  
The last few nightlies have been doing this again...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.2 → ---

    
    

    
  
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
Status: REOPENED → RESOLVED
Closed: 23 years ago → 19 years ago
Resolution: --- → FIXED
Product: Core → SeaMonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: