Samir Gehani Reporter
	Description • 23 years ago

Checkins between 2001-11-06 03:00:00 and 2001-11-07 09:00:00 to
mozilla/content/xul/templates caused a regression where the list of search
engines in the search sidebar tab is empty first time you view it.  If you close
the sidebar tab and reopen it the <menulist/> is populated correctly.

	Samir Gehani Reporter
	Comment 1 • 23 years ago

Narrowed it down to the checkin for bug 100952:
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=waterson&whotype=regexp&sortby=Date&hours=2&date=explicit&mindate=11%2F06%2F2001+22%3A00%3A00&maxdate=11%2F06%2F2001+23%3A00%3A00&cvsroot=%2Fcvsroot>

	Samir Gehani Reporter
	Comment 2 • 23 years ago

Over to waterson.

	Brian Nesse (gone)
	Comment 3 • 23 years ago

I spent some time looking into this.

It appears that the syntax at line 198 in search-panel.js:
  var basicEngines = basicEngineMenu.childNodes[1];
is no longer valid or has changed. It is throwing a JS warning/error (I don't
recall which right now). I think it is a "basicEngines has no properties"
warning. I can't check right now, I'm pulling the tree...

	Samir Gehani Reporter
	Comment 4 • 23 years ago

Actually, |childNodes| is still a valid array.  If you open a window with the
search tab open in the sidebar (see the js error on the js console), then open a
new window with the search tab still open the error won't appear on the console
and the menulist will be populated correctly.  So once this bug is fixed you
will no longer see the js error on the console.  

Also note, the same menulist is built from a template in the search prefs panel.
 If you start your browser with sidebar closed (or sidebar open but the search
tab not selected), then open the search pref panel you will see an empty
menulist where you would normally expect the list of search engines from which
you may select your default.

This leads me to assert that only the first time the template is being built for
the search engines datasource, some failure occurs.

Nominating for mozilla0.9.6.  CC'ing Jatin to release note this in the event
that is not fixed for mozilla0.9.6.

	Chris Waterson Assignee
	Comment 5 • 23 years ago

sgehani: I think the patch in bug 106749 might fix this: could you give it a try?

	Chris Waterson Assignee
	Comment 6 • 23 years ago

Urp, spoke too soon. Sorry!

	Chase Tingley
	Comment 7 • 23 years ago

According to a PR_LOG call I stuck in to the template building code, we're
bailing because while NC:SearchEngineRoot is in the activation stack, the search
plugins are being asserted in as children.

	Chris Waterson Assignee
	Comment 8 • 23 years ago

tingley fingered it. The problem is that the internet search datasource was
relying on the template builder to _not_ stifle re-entrant assertions. Instead
of letting GetTargets return, it assumed that OnAssert would push the values to
the template builder.

The fix is to simply do the mInner->GetTargets after the search datasource has
done its DeferredInit.

	Chris Waterson Assignee
	Comment 9 • 23 years ago

trip down memory lane?

	Robert John Churchill
	Comment 10 • 23 years ago

Asuming the fix works (my tree is bogus right now, so can't easily run with it),
its a simple dandy change.  r=rjc

	Chase Tingley
	Comment 11 • 23 years ago

I've had trouble reproducing the bug in the sidebar (dunno why), but saw it in
the prefs panel every time.  The patch fixes it -- i'd back rjc's r= with my own.

	Robert John Churchill
	Comment 12 • 23 years ago

BTW:  I unhorked my tree, reproduced the problem, and applied the change, which
fixed it for me.

	Tuukka Tolvanen (sp3000)
	Comment 13 • 23 years ago

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

	Chris Waterson Assignee
	Comment 14 • 23 years ago

c'mon hyatt, don't hold out on me. gimme the sr= I crave!

	David Hyatt
	Comment 15 • 23 years ago

sr=hyatt

	Chris Waterson Assignee
	Comment 16 • 23 years ago

Fix checked in on the trunk.

	Christopher Blizzard (:blizzard)
	Comment 17 • 23 years ago

a=blizzard on behalf of drivers for 0.9.6

	Chris Waterson Assignee
	Comment 18 • 23 years ago

Fix checked in on mozilla-0.9.6 branch.

	sairuh (rarely reading bugmail)
	Comment 19 • 22 years ago

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]