Open Bug 65453 Opened 19 years ago Updated 10 years ago

wrong document base with relative URLs in combined search [multi-engine(aggregate) search]

Categories

(SeaMonkey :: Search, defect, major)

defect
Not set
major

Tracking

(Not tracked)

People

(Reporter: studer, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted, intl)

Attachments

(4 files)

Mozilla takes chrome://communicator/content/search/ as base-dir for search-items
listed in the combined-search. So if a result page provides relative URLs the
link won't point to the right page.
Instead Mozilla should take the same folder as base folder where the action-file
specified by the search plugin (<SEARCH
action="http://server.com/folder/file.cgi">) is located.
I've written a plugin for mySQL-Documentation Search. Maybe you'll find that on
http://sherlock.mozdev.org/download.html so you can confirm this bug.
you can also confirm this bug with the "Comprehensive Perl Archive Network
(CPAN)"-plugin. Download it from http://sherlock.mozdev.org/download.html
Be sure you select more than one search engine to get a combined search.
Confirming this. When you search with only the CPAN search ticked in the
sidebar, the links will work from the sidebar. However if you have more than one
search engine ticked, the split window appearing in the browser itself will keep
the relative links.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: wrong document base in combined search → wrong document base in combined search (internetresults.xul)
Marking nsbeta1+, p3, mozilla0.9, matt take a look into this, please.
Keywords: nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
nav triage team:

Pushing out to future and p5, don't have time for this in the current development 
cycle.
Priority: P3 → P5
Target Milestone: mozilla0.9.2 → Future
*** Bug 98253 has been marked as a duplicate of this bug. ***
Any chance this bug gets fixed in the near future?
btw shouldn't this be OS all platform all?
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 110577 has been marked as a duplicate of this bug. ***
reassigning matt's old bugs to default owner.
Assignee: matt → sgehani
Is the problem described in bug 81643 the same issue?
Yes it is
So what is to be done? One dependent of the other, or purely and simply a dupe?
*** Bug 81643 has been marked as a duplicate of this bug. ***
Keywords: helpwanted, intl
Priority: P5 → P3
Summary: wrong document base in combined search (internetresults.xul) → wrong document base with relative URLs in combined search [multi-engine(aggregate) search]
Depends on: 171383
Blocks: 171383
No longer depends on: 171383
I think this is a regression. Previously, only the URLs in the lower part of a
multi-engine search would not be correct. Now if you have a multi-engine search
and display only the results of one engine, then you can see the same behavior
of the Search-engine's page. Highly visible bug, because the images (on google
for example) don't load. See attachment. Therefore, increasing severity.
Severity: normal → major
This patch workaround the bug by providing the plugin writer with a way to
specify a base URL to prepend to the relative uri found.
The following attachement is a plugin for freshmeat that uses this new feature
(freshmeat uses relative urls)
plugin for testing patch. Try it with and without baseURL
gif for freshmeat plugin
Product: Core → SeaMonkey
Assignee: samir_bugzilla → nobody
Priority: P3 → --
QA Contact: claudius → search
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.