101515 - QuickSearch: page footer's 'find' should allow searching

Status: RESOLVED FIXED

(Bugzilla :: User Interface, enhancement, P2)

Description

[Vidar B. Haarr (old account)]

when you go to http://bugzilla.mozilla.org/, you are allowed to enter both
search terms and a bug ID in the text-box.

This should be implemented for the page-footer in bugzilla as well.
now all you can do is write a bug ID. if you try to type any text or anything
else than numbers, it gives you "Error: The bug number is invalid".

Comment 1

[Andreas Franke (gone)]

Yes, I had the same idea. However, I'm not sure if this should be marked
dependent on bug 76484 or a duplicate of bug 102691...

Comment 2

[Stephen Lee]

Attachment: Patch based on 2.14 codebase

This is how I did it on our Bugzilla installation.

Comment 3

[Vidar B. Haarr (old account)]

What is keeping this from getting into the tree ?

Comment 4

[Dave Miller [:justdave]]

never got targetted?

I agree, this should be in.  My only concern is that looking up by bug_id is not
broken if you don't have Javascript available, but I think the current
QuickSearch engine allows for that.

Setting for 2.18.  We shouldn't have much trouble getting this in after 2.16
ships, assuming non-javascript use of bug IDs isn't broken.

Comment 5

[Andreas Franke (gone)]

Attachment: Screenshot (just look at the footer)

Bug number lookup still works, even with JavaScript disabled.

The patch does not work with the current cvs version any more, since the
QuickSearch API has been changed to take the text value as a param. The
relevant fragment of my current CGI.pl is attached below.

The patch removes the "bug #" between the "Find" button and the text input
field, and it removes the size=6 attribute from the text input field, so the
layout changes significantly. Some people may be opposed to this, but it
improves usability when used for QuickSearch since more text can be entered
visibly. On the other hand, it is probably not very desirable for those who
have JavaScript turned off.

Long-term, I'd probably prefer a QuickSearch textbox in the top right corner on
every page.

<FORM NAME="f" METHOD="GET" ACTION="show_bug.cgi" 
      ONSUBMIT="QuickSearch(f.id.value); return false;">
<TABLE width="100%"><TR><TD>
Actions:
</TD><TD VALIGN="middle" NOWRAP>
<a href="enter_bug.cgi">New</a> | 
<a href="query.cgi">Query</a> |
<a href='query.cgi?counts=1'>Counts</a> | 
};

    if (-e "query2.cgi") {
	$html .= "[<a href=\"query2.cgi\">beta</a>]";
    }
    
    $html .= qq{ 
<!--
<INPUT TYPE="SUBMIT" VALUE="Find"> bug \# 
<INPUT NAME="id" SIZE="6">
  -->
<script language="JavaScript" src="localconfig.js"></script>
<script language="JavaScript" src="quicksearch.js"></script>

<input type="submit" value="Find">
<input type="text" name="id">
<a href="quicksearch.html">[Help]</a>

Comment 6

[Andreas Franke (gone)]

There is another problem: If the form is named "f" as it is done in the patch,
then the original quicksearch textbox on the bugzilla front page (index.cgi)
does not work any more, since there are then two forms with the same name, and
(at least in Netscape 4) it seems that the last one is used when f.id.value is
computed. 
Renaming the form name="f" to name="f1" and f.id.value to f1.id.value in CGI.pl
fixed it for me.

Comment 7

[Stephen Lee]

On our setup, I left the default configuration of an index.html as the main 
page, so there is no clash with the page footer as index.html doesn't have one.

However, from the other stuff you said, it sounds like my patch is obsolete 
anyway. I'd suspected it probably would be, but posted for information.

Comment 8

[Bradley Baetz (:bbaetz)]

Comment on attachment 66733 [details] [diff] [review]
Patch based on 2.14 codebase

needs-work per comments

Comment 9

[Stephen Lee]

Attachment: Patch V2: vs. default 2.16 template

Post-templatisation, this is done completely in the template. Having now
installed 2.16 and being in the process of customising, I can create an updated
patch.

This patch leaves the overall appearance alone if javascript is disabled, and
modifies the form layout to remove the text "bug #" and widen the text box
otherwise.

The form name is "footersearch" in order to avoid conflicts with any other
quicksearch forms that may be present on the page.

Comment 10

[Dave Miller [:justdave]]

The User Interface component now belongs to Gerv.  Reassigning all UNCONFIRMED
and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component
owner) to Gerv.

Comment 11

[Dave Miller [:justdave]]

Reassigning back to Myk.  That stuff about Gerv taking over the User Interface
component turned out to be short-lived.  Please pardon our confusion, and I'm
very sorry about the spam.

Comment 12

[Dave Miller [:justdave]]

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

Comment 13

[Asa Dotzler [:asa]]

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

Comment 14

[Dave Miller [:justdave]]

Comment on attachment 103308 [details] [diff] [review]
Patch V2: vs. default 2.16 template

this has bitrotted

Comment 15

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 16

[Dave Miller [:justdave]]

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

Comment 17

[Stephen Lee]

Just thought I'd comment that I now do this as a customised *header* which just 
contains a quicksearch form as part of the layout, and it is unlikely that I 
will post an updated version of my previously submitted patches for this bug.

I still think it would be nice for SOME form of simple search to be available 
on every page, but the general text search (currently referred to as "Find a 
specific bug" for some reason) would probably be the appropriate back-end to 
use for that now.

Comment 18

[Jacob Steenhagen]

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

Comment 19

[Jacob Steenhagen]

Personally, I think we should either port quicksearch to perl (bug 70907) or,
even better, expand the simple search to allow for some of the most used
quicksearch options (any body know what those are?? Does anybody even use
quicksearch for anything more than a keyword type search?). We could then use
that search as our footer (or header, or whatever) search. That would save us
from having to load all that JavaScript for every page, too.