Closed Bug 78771 Opened 23 years ago Closed 23 years ago

second instance of an autocomplete widget fails to initialize outliner view

Categories

(SeaMonkey :: Location Bar, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: scttran, Assigned: hewitt)

References

Details

(Keywords: regression, Whiteboard: MUST HAVE)

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010503
BuildID:    2001050304

When more than one browser window is open, the autocomplete is blank for all
windows except for the original one.

Reproducible: Always
Steps to Reproduce:
1.Open up Mozilla
2.Try out Autocomplete (Observe Autocomplete working)
3.Open up another browser window
4.Observe on all new browser windows create, autocomplete is blank

Actual Results:  Autocomplete blank on all new instances of browser windows

Expected Results:  Autocomplete should work for all instances of browser windows
as expected
I can't reproduce on windows with 5/2 build.
Component: Browser-General → URL Bar
QA Contact: doronr → claudius
I've been seeing this problem all day too, same build (2001050304). The same
steps scott mentioned are sufficient to reproduce the bug.
I am now seeing this in a 5/3 build.  However, I just updated my tree this
morning and I am not seeing it with my local build.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I saw this bug on Win98 running Win32 build 2001050304.
i'm seeing this on win2k with 2001050404

also, after typing something partially into the url bar (i.e www) then right
clicking on links in the current page no longer brings up the context menu. 
however if you type "www." then the right click menus work again.

wierd.
*** Bug 78977 has been marked as a duplicate of this bug. ***
This definitely regressed after Hyatt landed his fix for the 800k leak that I
had caused in the outliner widget.
*** Bug 78726 has been marked as a duplicate of this bug. ***
*** Bug 79479 has been marked as a duplicate of this bug. ***
Summary: Autocomplete blanks out on new instances of browser windows → second instance of an autocomplete widget fails to initialize outliner view
*** Bug 79524 has been marked as a duplicate of this bug. ***
Keywords: mailtrack
I'm seeing this problem on Build 2001051109 on Mac OS 9.1, so it's not just a PC
problem.
Setting Platform=All.
Hardware: PC → All
*** Bug 80256 has been marked as a duplicate of this bug. ***
This is also affecting the ability to enter more than just one recipient to an
e-mail using the autocomplete feature from the address book (4 dupes just for
that) :(

This is highly annoying since I am forced to go to the address book itself and
scroll all over the place to get the addresses I want to include (this is made
even worse by the missing feature in the AB of typing the first letter of the
name and having the AB scroll to the first occurrence of that letter - ARGH)

This is a baaad bug. Why is there no target milestone set yet? Shouldn't the
"ns" keywords be plussed (e.g. "nsCatFood+")?

I don't mean to be impolite, but this bug has a VERY high proportion of
non-netscape persons on the CC: list, indicating a major "regular" user
interest/concern.
I spoke to hyatt about this last week.  He's pretty certain this was a
regression he caused while trying to fix a leak in outliner, and he seems to
have some idea how to fix this.
Assignee: hewitt → hyatt
Status: ASSIGNED → NEW
Autocomplete doesn't work on the first window. See bug 80287.
Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
umm, i think you forgot to check in your fix...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
As per hyatt's instructions reassigning this to hewiitt...
Assignee: hyatt → hewitt
Status: REOPENED → NEW
This works in the browser as of 2001051120, but not in mail...
Not on my system (Win98)...   2001051120 browser still has the problem
originally described here.
hmm wierd I just got it work... now it doesnt work anymore...
Does not work in Build 2001051404 on OS 9.1.  Only the first window loads a
proper autocomplete menu -- all others load blanks.
still broken on win32-installer 2001-0514-04 as well.

Note: if you start "mozilla -mail" autocomplete doesn't even work in the first
browser window.
*** Bug 80750 has been marked as a duplicate of this bug. ***
*** Bug 80287 has been marked as a duplicate of this bug. ***
*** Bug 80750 has been marked as a duplicate of this bug. ***
Blocks: 17880
seeing this bug on Win2K 2001051604

I get the following JavaScript Strict Warnings for every Browser window I open:

Warning: reference to undefined property this.oninit
Source File: chrome://global/content/autocomplete.xml#autocomplete.fireInit()
Line: 1

Warning: function fireInit does not always return a value
Source File: chrome://global/content/autocomplete.xml#autocomplete.fireInit()
Line: 3, Column: 7
Source Code:

Warning: function fireTextRevert does not always return a value
Source File: chrome://global/content/autocomplete.xml#autocomplete.fireTextRevert()
Line: 3, Column: 7
Source Code:

Warning: function fireTextCommand does not always return a value
Source File: chrome://global/content/autocomplete.xml#autocomplete.fireTextCommand()
Line: 3, Column: 7
Source Code:

Warning: function processKeyPress does not always return a value
Source File: chrome://global/content/autocomplete.xml#autocomplete.processKeyPress()
Line: 52, Column: 21
Source Code:
          return true;

Warning: function readRDFString does not always return a value
Source File:
chrome://navigator/content/urlbarBindings.xml#autocomplete-result-popup.readRDFString()
Line: 4, Column: 7
Source Code:

Warning: redeclaration of var sel
Source File:
chrome://navigator/content/urlbarBindings.xml#autocomplete-result-popup.selectBy()
Line: 9, Column: 14
Source Code:
          var sel = this.getNextIndex(aDir, aAmount, this.selectedIndex,
view.rowCount-1);


I see following Warnings when I first start editing address URL Bar:

Warning: reference to undefined property this.currentSearchString
Source File: chrome://global/content/autocomplete.xml#autocomplete.startLookup()
Line: 2

Warning: reference to undefined property this.mLastResults[name]
Source File: chrome://global/content/autocomplete.xml#autocomplete.startLookup()
Line: 12


I see following Warning repeated 10 times for every char I type, when editting
address URL Bar:

Warning: reference to undefined property this.mInputFilter
Source File: chrome://global/content/autocomplete.xml#autocomplete.filterString()
Line: 1


I get this warning when I hover mouse in and out of *working* autocomplete list:

Warning: reference to undefined property this.engineIndex
Source File: 
Line: 1


I get following Warnings when I open second Browser window in which autocomplete
doesn't work:

Warning: reference to undefined property this.__AUTOCOMPLETE_BOX__
Source File:
chrome://global/content/autocomplete.xml#autocomplete-result-popup.textbox (getter)
Line: 0

Also as a result of this bug, seeing the following JavaScript Error while
hovering mouse over not-working autocomplete list:

Error: obox has no properties
Source File:
chrome://global/content/autocomplete.xml#autocomplete-outlinerbody.getHoverCell()
Line: 7

Hope this could be of some help :o)

I hate to give this back to hyatt, but I have to.  It was never really fixed in
the first place.
Assignee: hewitt → hyatt
*** Bug 81325 has been marked as a duplicate of this bug. ***
10 dupes, adding Mostfreq keyword...
Keywords: mostfreq
*** Bug 81525 has been marked as a duplicate of this bug. ***
*** Bug 81634 has been marked as a duplicate of this bug. ***
*** Bug 81670 has been marked as a duplicate of this bug. ***
Whiteboard: want for mozilla 0.9.1
*** Bug 81888 has been marked as a duplicate of this bug. ***
No longer blocks: 38865
*** Bug 82218 has been marked as a duplicate of this bug. ***
On any 0.9+ build, autocomplete of web addresses (do not confuse with search
autocomplete) does not work
Seems like search autocomplete disables the use of web autocomplete, since it
works in 0.9 when search autocomplete was not there.

Using 2001051821 on linux here.
I am being told that starting mail and navigator at startup disables web address
autocomplete

Noted. Will try a newer build later.
So what is going on with this bug?
Update: Now that i only start navigator without mail, autocomplete works in the
first window. On the second window, autocomplete DOES appear, but the list of
web addresses look empty, but if you click on somewhere in the list, it really
takes you to that webpage (blindly)

I am giving this bug a vote :)
BTW, Francisco's bug 82174 should be marked as dup of this one. 
*** Bug 82174 has been marked as a duplicate of this bug. ***
I have a patch.

Turns out the problem was not caused by hyatt's fix for the big leak I had
caused, but by a separate fix for an outliner crasher.  In
nsOutlinerBodyFrame::SetView (as of rev 1.44) we are now returning if
mOutlinerBoxObject is null without storing the view.  So, to compensate,
nsOutlinerBoxObject::SetView needs to make sure the view was actually stored on
the bodyframe, and if not, cache it.
Assignee: hyatt → hewitt
Attached patch patch to fixSplinter Review
Great. As soon as you put this fix in a nightie please tell us so we can test it
*** Bug 82405 has been marked as a duplicate of this bug. ***
Francisco León wrote:
> Great. As soon as you put this fix in a nightie please tell us so we can test it

Methinks Mozilla would not like wearing lingerie.  ;-)  (Of course you meant
nightly, but I've never turned down the opportunity for a good laugh...)
"me thinks" that i said "nightie" as a diminutive of night, not nightly, and
also "me thinks" you should not waste bugzilla's messages on such non-important
things. Keep your comments bug-related.
sr=hyatt
Status: NEW → ASSIGNED
Keywords: nsbeta1nsbeta1+
Target Milestone: --- → mozilla0.9.1
blizzard said a=blizzard

fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Verified that this is fixed as of 2001052330
Status: RESOLVED → VERIFIED
WFM linux 2001052406

Great work
WFM on Mac Build 2001052508.  Too bad I can't say the same for the senses of
humor of some people...
this is broken again in 2001-0603-20 win32-installer.
Reopening.
Also broken in 2001060404 trunk for Mac.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Someone mark this one regression and blocker for 0.9.1
Joe, it's back.  Any idea what happened?
Keywords: regression
Whiteboard: want for mozilla 0.9.1 → MUST HAVE
2001060221 is also broken
I seem to remember hearing that this regressed right after hyatt's big
style-system landing, so it could be related to that.
2001060121 is also broken
Now this is weird. 2001060121 autocomplete is broken on the first instance, but
on the second it works ok!  *HINT HINT*
I will try an earlier build
Francisco:  There is a related bug 83632
That bug should be marked as a dependency, and mark both as blockers
2001053121 is also broken. I really did not test the lastest build on the second
window, since i did not know of this new bug
2001053021 works fine, on first and second instances, exactly like bug 83632
I dont see why this bug was reopened.... There is no need for this.... Bug 83632
already handles the bug about the FIRST instance of autocomplete in the BROWSER
not working... This bug deals with SECOND instance of ALL autocomplete widgets
not working. This fix is totally unrelated to 83632, as this was fixed on 5/23
and 83632 broke on 5/31... Changing this back to fixed, move all discussion to
bug 83632
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
marking VERIFIED Fixed (again) based on comments
Status: RESOLVED → VERIFIED
*** Bug 86334 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: