512894 - links to search results return "Firefox can't find the server at kb." error

Status: VERIFIED FIXED

(support.mozilla.org :: General, defect)

Description

[bretttt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: 

links on the search result page are malformed, [https://kb/Het+door+Firefox+gebruikte+e-mailprogramma+wijzigen?s=gmail] for example.   

Reproducible: Always

Steps to Reproduce:
1.enter url [https://support.mozilla.com/tiki-newsearch.php?where=all&q=gmail&sa=]
2.click one of the search result links or the ask a support question instead link
3.
Actual Results:  
go to error page

Expected Results:  
go to correct page

Comment 1

[bretttt]

This happens only when I am logged in.  Search results are totally different when I log out and all links for searches returned are clickable.   All addons are disabled.

Comment 2

[David Boswell]

Changing product to support.mozilla.com.

Comment 3

[Noah (NoahSUMO/SolidSnake) [:Noah]]

I confirm seeing the problem as well using a 6/26 & 7/18 nightly builds.

We both went thru our addons, and disabled them. Even as far as uninstalling some of them (like Adblock Plus) for example. The problem still persisted.

You MUST be logged in to SUMO to see the problem. Please remember that, I kept forgetting. :/

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

I can't reproduce, even when logged in.

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #4)
> I can't reproduce, even when logged in.

I take that back; Admin accounts work fine, but Contributor accounts give the behavior Noah and bretttt describe.

Comment 6

[[:Cww]]

Is there any reason why searches should be different for contributors or regular users?  Also I think this was working before so I suspect this may have to be bumped to IT.

Comment 7

[Chris Ilias [:cilias]]

If I log in as a Contributor, I still cannot reproduce. Is this specific to a build of Firefox (trunk)?

Comment 8

[[:Cww]]

Maybe it's a specific DB slave?

Comment 9

[Noah (NoahSUMO/SolidSnake) [:Noah]]

Cilias, not specific to a trunk build as Brett is using a official 3.5.1. Take a gander at his UA in comment 0. :P

I had a feeling it had something to do with accounts belonging to specific groups as Ricmacas couldn't reproduce it. So I found that funny.

Comment 10

[Paul Craciunoiu [:paulc]]

I think let's wait and see if newsearch rewrite fixes this.

Comment 11

[James Socol [:jsocol, :james]]

Now that newsearch is on stage, can we reexamine this?

Comment 12

[James Socol [:jsocol, :james]]

Since we didn't land the newsearch rewrite, we need to address this ASAP, ie: 1.4.1.

Comment 13

[Paul Craciunoiu [:paulc]]

Attachment: v1

I __cannot wait__ to rewrite the entire search. It is so ridiculously confusing :(

Comment 14

[James Socol [:jsocol, :james]]

Comment on attachment 404335 [details] [diff] [review]
v1

Seems to be working for me. I'm a little curious how this was falling through.

Comment 15

[Paul Craciunoiu [:paulc]]

r52789 (trunk only)

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED.

Litmus: https://litmus.mozilla.org/show_test.cgi?id=9560

Please commit to production, thanks!

Comment 17

[Paul Craciunoiu [:paulc]]

r52795 (prod) / r52796 (fennec)
In case fennec wish to use search before we sync, they shouldn't have this problem.

Comment 18

[David Tenser [:djst]]

Should this be Tiki upstreamed, or do we wait for the new(er) search?

Comment 19

[Paul Craciunoiu [:paulc]]

Definitely wait.