153874 - Query In Sidebar doesn't work

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Andreas Giegeling]

In Bugzilla (2.16rc2) the Query-Line doesn't work well. It generates a "double"
URL, like:

http://server/bugzilla/http://server/bugzilla/....

Our Bugzilla-Admin could not solve the problem.

Andi

Comment 1

[Jouni Heikniemi]

Works for me, both on trunk tip and 2.16rc2. Can you still make this appear?

Comment 2

[Andreas Giegeling]

Yes, I can!

Comment 3

[Jouni Heikniemi]

What's your urlbase setting in your bugzilla's "edit parameters" screen?

Comment 4

[Andreas Giegeling]

It says:

http://172.30.3.69/bugzilla/

Comment 5

[Jouni Heikniemi]

Umm, hmm. So do I understand you correctly: When you type in a query term like
'foobar' and tap enter, you get a wrong URL. Can you paste the whole generated
url into the bug?

Do the other links in the sidebar work fine? If you install a sidebar from a
different installation (say bugzilla.mozilla.org), does it work properly?

Comment 6

[Andreas Giegeling]

The links are working fine.

If I search for "123" the URL is:

http://172.30.3.69/bugzilla/http://172.30.3.69/bugzilla/show_bug.cgi?id=123

Comment 7

[Jouni Heikniemi]

What does your var bugzilla = "" line in localconfig.js say? 

Comment 8

[Andreas Giegeling]

It says:

bugzilla = "http://172.30.3.69/bugzilla/";

Comment 9

[Jouni Heikniemi]

Ok, I rest my case. It works for me every time ;-) 

caillon, afranke, kiko: do you have any ideas?

Comment 10

[Peter Henderson]

*** Bug 160668 has been marked as a duplicate of this bug. ***

Comment 11

[Peter Henderson]

This is a problem with the relationship of quicksearch.js and the output from
sidebar.cgi (template file is template/en/default/sidebar.xul.tmpl).

http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/quicksearch.js#50
http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/template/en/default/sidebar.xul.tmpl#43
In quicksearch.js, the function go_to() calls the function load_relative_url()
in the page generated by sidebar.cgi. go_to() passes the absolute url of the
query page, but load_relative_url() expects a relative url, to which it prepends
'[% Param('urlbase') %]', which evaluates to 'http://bugzilla.mozilla.org/' on
b.m.o.

To fix this, either go_to() needs to be rewritten to strip the urlbase before
passing it to load_relative_url(), or else go_to() should instead pass the url
to a new function, something along the lines of load_absolute_url(). Somebody
with authority over Bugzilla tell me which solution is better, and I'll make a
patch.

(Also changing component because User Interface is for "General issues having to
do with the user interface cosmetics (not functionality) including cosmetic
issues, HTML templates, etc" and this is functionality.)

Comment 12

[Adrian Ulrich]

*** Bug 161244 has been marked as a duplicate of this bug. ***

Comment 13

[Bradley Baetz (:bbaetz)]

kiko - you own quicksearch. Which solution is better?

Comment 14

[Christian Reis]

The second solution avoids string manipulation and is probably easier to
maintain. If you want to take a shot at it, I'd be happy to review.

Comment 15

[Bradley Baetz (:bbaetz)]

/me has a serious lack of time, and invites someone else to do it

:)

Comment 16

[Peter Henderson]

Attachment: Second solution

This patch adds a function load_absolute_url() to sidebar.xul.tmpl which is
basically a mnemonic for _content.location = foo;. This function is called in
quicksearch.js instead of load_relative_url() for doing a query, since the
function go_to() receives an absolute URL. (sidebar.xul.tmpl still uses
load_relative_url() internally.)

Comment 17

[Christian Reis]

I'm looking at this, but I really don't understand how *I* can't reproduce this
problem. Ah, yes I can. I can see that if you set bugzilla to *anything*
quicksearch breaks. Good catch.

Now this has shown itself to be a tricky one, because I can't really see *why*
we need var bugzilla in the first place. The original author probably knows
(Chris, apparently) but I can't see why we would need it anyway - after all,
show_bug.cgi today is always on the same directory level as any other bugzilla
script. If we *are* going to move to hierarchical organization (and I can't see
why we would right now) then this change is appropriate, EXCEPT for the next reason.

Having `var bugzilla' in *localconfig.js* makes us have to configure the value
in two places: in both params and in javascript. I find this quite evil (it's
the real cause of this bug) and I would rather see it fixed before hacking more
on this already unstable foundation.

Anybody have an idea of where bugzilla_baseurl (better global variable name,
too) could be set? It has to be javascript code generated through a cgi - maybe
its time localconfig.js grows up and stops duplicating data? Peter, would you be
up for making a cgi localconfig.js?

Comment 18

[Peter Henderson]

Make a cgi that generates localconfig.js? I'll give it a shot. Sounds like a new
bug though, as this is about query in the sidebar, not rewriting localconfig.

Does my patch work on anybody else's installation? If so, it could be checked in
for now so the sidebar query will work while a localconfig.js.cgi or whatever
(localconfig.js.tmpl might be a better way to do it, I haven't thought too much
about it yet) is in the works.

Comment 19

[Christian Reis]

I'd be fine with you filing a new bug on a cgi (a simple cgi is fine, no need to
templatize it) and having this one depend on it, to avoid going back and
refixing it.

Comment 20

[Bradley Baetz (:bbaetz)]

We already have a bug on such a cgi...

Comment 21

[Christian Reis]

And the localconfig.js file is quite simple, too; basically pull in params.

Comment 22

[Myk Melez [:myk] [@mykmelez]]

The Bugzilla variable is useful for non-CGI-based Bugzilla client scripts like
duplicates.xul (bug 156548).  A CGI for generating localconfig.js has already
been done over in bug 72837.

Comment 23

[Peter Henderson]

*** Bug 167132 has been marked as a duplicate of this bug. ***

Comment 24

[Peter Henderson]

What's happening here? Last thing that happened was I volunteered to code a cgi
to make localconfig.js, and then myk said one already exists, so I didn't work
on it. Is my patch going to be checked in so bugzilla installations will work in
the meantime, or are we waiting for the cgi to be polished before anything
further happens?

Comment 25

[Bradley Baetz (:bbaetz)]

Comment on attachment 95222 [details] [diff] [review]
Second solution

I can repro this on bmo, as well as locally.

kiko, can you r= this?

Comment 26

[Andreas Franke (gone)]

Looks good to me.

The original reason for the "bugzilla" variable in localconfig.js was that
quicksearch can be used as a standalone search tool. For example, I can put
localconfig.js and quicksearch.js as well as quicksearch.html or
quicksearchhack.html somewhere on a web server that does not have anything to do
with bugzilla, and manually point it to some existing bugzilla installation by
setting the "bugzilla" variable in localconfig.js to something like
"http://bugzilla.mozilla.org/" or "http://bugzilla.mathweb.org:8000/".

On the other hand, if quicksearch is used as part of a complete bugzilla
installation, then it is not needed and can usually be left empty.

Comment 27

[Christian Reis]

Comment on attachment 95222 [details] [diff] [review]
Second solution

Yep, I'm fine with this; note that my previous comment still is valid - we
still need to set the bugzilla url base in two places. I understand the need
for standalone clients, though, so I guess this is the only way to go.

Comment 28

[Dave Miller [:justdave]]

*** Bug 184181 has been marked as a duplicate of this bug. ***

Comment 29

[Senji]

Having just downloaded the Bugzilla sidebar today I'm seeing this problem
without having changed any settings...

I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910

Comment 30

[Dave Miller [:justdave]]

-> patch author

Comment 31

[Dave Miller [:justdave]]

This sat here way too long, and I apologize for not getting it checked in
sooner.  (Was assigned to Myk, who was on vacation, and nobody else picked up on
it)  I'm glad it still applied cleanly and didn't bitrot in the month it sat
here :-)

Checking in quicksearch.js;
/cvsroot/mozilla/webtools/bugzilla/quicksearch.js,v  <--  quicksearch.js
new revision: 1.10; previous revision: 1.9
done
Checking in template/en/default/sidebar.xul.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/sidebar.xul.tmpl,v  <-- 
sidebar.xul.tmpl
new revision: 1.7; previous revision: 1.6
done

Comment 32

[Bill Mason]

I just added the Bugzilla sidebar today, and this problem is still present. 
Using the search field generates URLs that start out
"http://bugzilla.mozilla.org/http://bugzilla.mozilla.org/buglist.cgi"

Comment 33

[Benjamin Smedberg]

Bill, where did you test this? It was fixed in the bugzilla CVS tree, but that
doesn't mean that http://bugzilla.mozilla.org has been updated yet.

Comment 34

[Bill Mason]

I'm not sure I get the question.  I downloaded the sidebar from the link on
http://bugzilla.mozilla.org/ and it's broken just as previously noted in this bug.

Comment 35

[Benjamin Smedberg]

Bill, bugzilla.mozilla.org is not the same thing as "bugzilla". "Bugzilla" is a
tool that many sites use (including bugzilla.mozilla.org). bugzilla.mozilla.org
does not update to the latest version of "bugzilla" immediately, but waits a
while. So this bug is fixed, and it will appear on bugzilla.mozilla.org the next
time bugzilla.mozilla.org is upgraded.

Comment 36

[Dave Miller [:justdave]]

*** Bug 218806 has been marked as a duplicate of this bug. ***

Comment 37

[Matt Leidholm]

This doesn't seem like a very hard problem to fix, especially seeing as it was
filed over a year ago.  Its a huge inconvenience to me and countless others as
well.  Either fix the sidebar or remove it, don't give people a broken one.