Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED

Status

SeaMonkey
Sidebar
--
major
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Paul Millar, Assigned: Karsten Düsterloh)

Tracking

(5 keywords)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.09 KB, patch
bsmedberg
: review+
jag (Peter Annema)
: superreview+
Mike Schroepfer
: approval1.8.0.2+
Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
: approval-seamonkey1.1a+
Details | Diff | Splinter Review
(Reporter)

Description

12 years ago
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

12 years ago
WFM with SeaMonkey/20050823 but reproducible with SeaMonkey/20050824 and SeaMonkey 1.0a, maybe related to (older Mac) bug 271314?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

12 years ago
(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

12 years ago
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
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

12 years ago
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
Flags: blocking-seamonkey1.0?

Comment 6

12 years ago
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...
Flags: blocking-seamonkey1.0? → blocking-seamonkey1.0-

Comment 7

12 years ago
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.
(Assignee)

Comment 8

12 years ago
Taking.
OS: Windows XP → All
(Assignee)

Updated

12 years ago
Assignee: sidebar → mnyromyr
(Assignee)

Comment 9

12 years ago
Created attachment 208785 [details] [diff] [review]
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.
Attachment #208785 - Flags: superreview?
Attachment #208785 - Flags: review?
(Assignee)

Updated

12 years ago
Attachment #208785 - Flags: superreview?(jag)
Attachment #208785 - Flags: superreview?
Attachment #208785 - Flags: review?(benjamin)
Attachment #208785 - Flags: review?

Comment 10

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

sr=jag
Attachment #208785 - Flags: superreview?(jag) → superreview+
(Assignee)

Updated

12 years ago
Keywords: regression
Attachment #208785 - Flags: review?(benjamin) → review+
(Assignee)

Comment 11

12 years ago
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.
Attachment #208785 - Flags: approval1.8.1?
Attachment #208785 - Flags: approval1.8.0.2?
Attachment #208785 - Flags: approval1.8.0.1?
Attachment #208785 - Flags: approval-seamonkey1.1?
Attachment #208785 - Flags: approval-seamonkey1.0?
(Assignee)

Comment 12

12 years ago
Rerequesting blocking&#8209;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. ;-) )
Flags: blocking-seamonkey1.0- → blocking-seamonkey1.0?
(Assignee)

Updated

12 years ago
Whiteboard: [checked-in on trunk, waiting for branch approval]
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
Attachment #208785 - Flags: approval-seamonkey1.1? → approval-seamonkey1.1+

Comment 14

12 years ago
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
Attachment #208785 - Flags: approval-seamonkey1.0? → approval-seamonkey1.0+

Comment 15

12 years ago
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.
Attachment #208785 - Flags: approval1.8.0.2? → approval1.8.0.2+
(Assignee)

Comment 16

12 years ago
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
Attachment #208785 - Flags: approval1.8.1?
Attachment #208785 - Flags: approval1.8.0.1?
(Assignee)

Updated

12 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8.0.1, fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [checked-in on trunk, waiting for branch approval]
Whiteboard: fixed-seamonkey1.0
(Assignee)

Updated

12 years ago
Flags: blocking-seamonkey1.0?
minor edit - changing fixed1.8.0.1 keyword to fixed1.8.0.2
Keywords: fixed1.8.0.1 → fixed1.8.0.2
Keywords: fixed-seamonkey1.0
Whiteboard: fixed-seamonkey1.0

Updated

11 years ago
Keywords: fixed-seamonkey1.1a
You need to log in before you can comment on or make changes to this bug.