Closed Bug 101515 Opened 23 years ago Closed 19 years ago

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


(Bugzilla :: User Interface, enhancement, P2)




Bugzilla 2.22


(Reporter: folk, Assigned: Wurblzap)



(Whiteboard: [blocker will fix])


(1 file, 2 obsolete files)

when you go to, 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".
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...
Summary: page footer's 'find' should allow searching → QuickSearch: page footer's 'find' should allow searching
Attached patch Patch based on 2.14 codebase (obsolete) — Splinter Review
This is how I did it on our Bugzilla installation.
What is keeping this from getting into the tree ?
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.
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.18
Attached file Screenshot (just look at the footer) (obsolete) —
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 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(; return false;">
<TABLE width="100%"><TR><TD>
</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>
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 is
Renaming the form name="f" to name="f1" and to in
fixed it for me.
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 on attachment 66733 [details] [diff] [review]
Patch based on 2.14 codebase

needs-work per comments
Attachment #66733 - Flags: review-
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

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

The form name is "footersearch" in order to avoid conflicts with any other
quicksearch forms that may be present on the page.
Attachment #66733 - Attachment is obsolete: true
Attachment #68093 - Attachment is obsolete: true
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.
Assignee: myk → gerv
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.
Assignee: gerv → myk
*** Bug 212417 has been marked as a duplicate of this bug. ***
*** Bug 145666 has been marked as a duplicate of this bug. ***
Comment on attachment 103308 [details] [diff] [review]
Patch V2: vs. default 2.16 template

this has bitrotted
Attachment #103308 - Flags: review-
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
*** Bug 262862 has been marked as a duplicate of this bug. ***
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.
*** Bug 286344 has been marked as a duplicate of this bug. ***
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.
Assignee: myk → wurblzap
Closed: 19 years ago
Depends on: 70907
Resolution: --- → FIXED
Whiteboard: [blocker will fix]
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.