318889 - No search results displayed when doing multisearch in sidebar search panel or main internetsearchresults.xul main page

Status: RESOLVED FIXED

(SeaMonkey :: Sidebar, defect)

Description

[Paul Millar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051202 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051202 SeaMonkey/1.5a

When you use the Advanced search option for the sidebar search panel and do a multisearch no search results get displayed in the sidebar search panel or in internetsearchresults.xul, although sidebar results get displayed on a single search.

Reproducible: Always

Steps to Reproduce:
1. Open search sidebar panel
2. Tick Google and DMOZ searches
3. Search for any keyword

Actual Results:  
No search results appear in sidebar or main results page

Expected Results:  
Search results should appear in both sidebar and main results page

This problem seems to be fixed if you change the position of the 'user' input tag.

Original Google input .src section:

<input name="q" user>
<input name="sourceid" value="mozilla-search">
<inputnext name="start" factor="10">
<inputprev name="start" factor="10">
<input name="ie" value="utf-8">
<input name="oe" value="utf-8">

Change the position of <input name="q" user>:

<input name="sourceid" value="mozilla-search">
<inputnext name="start" factor="10">
<inputprev name="start" factor="10">
<input name="ie" value="utf-8">
<input name="oe" value="utf-8">
<input name="q" user>

Multisearch results now work.

Comment 1

[zug_treno]

WFM with SeaMonkey/20050823 but reproducible with SeaMonkey/20050824 and SeaMonkey 1.0a, maybe related to (older Mac) bug 271314?

Comment 2

[RenegadeX]

(In reply to comment #0)
> This problem seems to be fixed if you change the position of the 'user' input
> tag.
> 
> Original Google input .src section:
<SNIPPAGE>
> Multisearch results now work.

I can confirm the bug on the latest Win32 versions of SeaMonkey (1.0b and 1.5a) (branch and nightlies) and both .exe and .zip installers (for 1.5a).

You do realize that re-ordering lines in search-engine .src files isn't going to work.. Mycroft has --- how many plugins already submitted???

Comment 3

[inconnu]

I can duplicate the bug on Debian GNU/Linux using 1.0b (SeaMonkey 1.0 Beta release):
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b

Comment 4

[Bruno 'Aqualon' Escherl]

I get the following JS console error during multisearch:

Error: navWindow.content.setInitialSort is not a function
Source File: chrome://communicator/content/search/search-panel.js
Line: 651

setInitialSort is defined in xpfe/components/search/resources/shared.js#385

None of those files were changed during the regression window from comment #1, so I don't know if this is really related to this bug.

Comment 5

[Ian Neal]

I suspect it was the checkin for bug 289362
Just to clarify steps:
1) Make sure advanced is selected for "Sidebar Search Tab Preference" under Internet Search preferences
2) Select any two search engines after selecting the All Engines option in the sidebar

Nominating for blocking seamonkey 1.0

Above JS console message appeared before 2005082406 builds too

Comment 6

[Robert Kaiser]

No patch and rarely used feature, so not blocking release for it.
Though it would be nice to get at least an intermediate fix, we'd be very likely to accept it for 1.1 and 1.0.x releases...

Comment 7

[Rob S]

Don't know about rarely used feature.

I use multi-engine search on a daily basis, and it would be a major dissappointemnt to me if it wasn't fixed ion the first seamonkey release.

Comment 8

[Karsten Düsterloh]

Taking.

Comment 9

[Karsten Düsterloh]

Attachment: heed GetInputs changes of bug 289362

Bug 289362 allows for search URIs without ? parameter, InternetSearchDataSource::GetInputs now takes care of (not) adding it. The callers ' usage of the result was changed accordingly, but one - and this kills multisearch here. This patch corrects that.

Comment 10

[jag (Peter Annema)]

Comment on attachment 208785 [details] [diff] [review]
heed GetInputs changes of bug 289362

sr=jag

Comment 11

[Karsten Düsterloh]

Comment on attachment 208785 [details] [diff] [review]
heed GetInputs changes of bug 289362

Requesting m.o branch approvals, too, since the xpfe file in question is also used by Firefox: low risk one-line fix for (in SM: highly) visible regression.

Comment 12

[Karsten Düsterloh]

Rerequesting blocking‑seamonkey1.0?, because this now has a fully reviewed patch and fixes an important feature that else would be broken completely in 1.0!
(I doubt the "rarely used" anyway. ;-) )

Comment 13

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 208785 [details] [diff] [review]
heed GetInputs changes of bug 289362

a=me for SM1.1
first-a=me for SM1.0, need one more

Comment 14

[Ian Neal]

Comment on attachment 208785 [details] [diff] [review]
heed GetInputs changes of bug 289362

a=me for SM1.0 (the 2nd needed one)
just have to wait for driver approval now

Comment 15

[Mike Schroepfer]

Comment on attachment 208785 [details] [diff] [review]
heed GetInputs changes of bug 289362

a=schrep for seamonkey.  Approving since we are past the 1.8.0.1 respin point and understanding is even though this is a shared file the changes are for SM only.

Comment 16

[Karsten Düsterloh]

Comment on attachment 208785 [details] [diff] [review]
heed GetInputs changes of bug 289362

Yes, the patched file position (InternetSearchDataSource::DoSearch) is only used when constructing the multisearch results RDF tree. SM/FF single engine search calls GetInternetSearchURL and load the resulting URI.

Checked in on MOZILLA_1_8_BRANCH and MOZILLA_1_8_0_BRANCH

Comment 17

[Dave Liebreich [:davel]]

minor edit - changing fixed1.8.0.1 keyword to fixed1.8.0.2