7/19 branch win98 In the URL bar, type "word1 word2" (use any terms you're interested in :-) Use the arrow key to do the search via the autocomplete widget. The result page will be the results for "word1%20word2". The search field on the page actually puts "word1%20word2" in as the search. We appear to be escaping the search terms when using the autocomplete widget :-(
are we supposed to know to convert from %20 to + ? isn't that a feature of the search engine?
adding joe hewitt since he wrote the autocomplete part.
which search engine are you using ? I'm using google and it wfm with 2001071913 (and loads of nightlies before)
Netscape search engine. Sorry if that's a Netscape only thing, I didn't think of that when I filed the bug. Is escaping the standard and correct thing to do then?
looks like we are inserting an extra 25 into the url: http://search.netscape.com/search.psp?charset=UTF-8&search=hello%2520world should be: http://search.netscape.com/search.psp?charset=UTF-8&search=hello%20world
So it looks like 1)the space is being escaped while it should turn into "+" 2)even so we go to http://info.netscape.com/fwd/clk61srurl2/http://search.netscape.com/cgi-bin/sear ch?charset=UTF-8&search=hello%20world and then get forwarded from the server to: http://search.netscape.com/search.psp?charset=UTF-8&search=hello%2520world I wonder if on the server they could change something to make it forward to: http://search.netscape.com/search.psp?charset=UTF-8&search=hello%20world Todd?
Matt, isn't that %2520 a double escaping symptom? I think I've seen this in other bugs where %20 logically turns into escape(%)20 = %2520. Do we know what's wrong on our end?
Adding Myron Rosmarin to cc list.
my, my, you guys are fast! The new Netscape Search 2.0 search results page was launched yesterday morning at 7am PDT. The problem described by this bug report was very real and has been corrected last night. Please check it out again ... I'm confident you'll see that this bug can be closed.
no, I just tried it and its still happening.
This is a bug on info.netscape.com's server. If you give info a %20, you end up searching for "%20". If you give it a +, you end up searching for "+". By the way, why is there a redirect? Shouldn't NS6.1 be sending users directly to search.netscape.com when they enter a search?
This just started working for me (but I did see the problem earlier). Steve, is it okay for you now?
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Nevermind... false alarm.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
on reinspection, there are essentially three conditions, two of which were fixed word1 word2 "enter" works fine search word1 word2 "enter" works fine word1 word2 "Search button click" still doesn't work correctly I will work quickly with AOLT to get this fixed.
Myron, just to be clear, there is another case that doesn't work: enter word1 word2, scroll down the autocomplete to Search selection and hit enter. This produces the same result as your failure case (clicking the search button to the right of the URL bar).
correct me if I'm wrong, but doesn't the auto-complete feature look at the Sherlock file? ... so if the Sherlock file is broken, the search will be broken too. If I'm correct, then once we fix the Netscape Search sherlock file, we'll correct this other condition.
The bug here is we are looking at spaces " " in the search term and escaping them to be %20. Then we send it to the server. I believe the server is then taking this term and not dealing with the %20 the way it used to and interpets it not as a space " " but as a real %20. We might be able to change the url in the sherlock file to make it work with the new search engine. This addes risk if we end of breaking this or getting the url wrong for international.
What Matt said.
Myron, since this sounds like it recently regressed on the server side, a server side fix is the ideal way to proceed. is there some eta we can add to the bugs status on this?
But there's no way to actually send a space character to info.netscape.com. HTTP urls don't contain spaces, so we have to send a + or a %20, or bypass info.netscape.com.
try again, it appears to be working
I'm removing PDT+ from this bug because its now fixed on the Netscape commercial side. On the Mozilla side of the tree (which also contains an old version of the Netscape Sherlock), interestingly, the old Sherlock does not exhibit this problem when there are multiple words, however the Netscape sidebar search results do not show. I think the new Netscape sherlock that works on the commercial side shd get checked in as NetscapeSearch.src on the mozilla side too. Too tired to do that just now, but we shd do it in time for mozilla0.9.3. making this bug nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Updating summary to reflect the Mozilla state.
Summary: URL bar search of "word1 word2" got results of "word1%20word2" → Netscape Search results do not show in sidebar anymore.
Please don't remove the PDT+. Add "fixed on branch" instead. (And add the vbranch keyword so QA will attack the fix in the next build.) Thanks!
Whiteboard: PDT+ fixed on branch
Wait! This bug hasn't been fixed at all. Vishy, I think you intended to update the summary of the bugscape bug about creating a new sherlock file. This bug is still alive and still needs attention on the server side. Myron, I tried again, and no it's still not working.
Summary: Netscape Search results do not show in sidebar anymore. → URL bar search of "word1 word2" got results of "word1%20word2"
Whiteboard: PDT+ fixed on branch → PDT+
OS: other → All
Hardware: PC → All
Whiteboard: PDT+ → PDT+ needs serverside attention
I just tested with todays download and it works fine. i think if we are still seeing problems that the code got pushed to some of the servers and not other servers.
I just tested with commercial branch build of 07/22 and it works fine. Blake could you check again, I'm pretty sure this is now working. marking fixed.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
fixed with 20010724 builds (checked the branch) marking VERIFIED Fixed
Status: RESOLVED → VERIFIED
*** Bug 93472 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.