Closed Bug 70907 Opened 24 years ago Closed 20 years ago

QuickSearch: port the JS code to perl (make it server-side)

Categories

(Bugzilla :: Query/Bug List, enhancement)

Product:
Bugzilla
Component:
Query/Bug List
Version:
2.11
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.22

People

(Reporter: afranke, Assigned: Wurblzap)

References

(
URL
)

Details

(Whiteboard: #*#* THIS BUG IS FIXED IN BUGZILLA 2.22. DO NOT COMMENT. #*#*)

Attachments

(1 file, 13 obsolete files)

Patch 2.4
90.03 KB, patch
wicked
: review+
Details | Diff | Splinter Review
Currently QuickSearch is a client-site JavaScript-based tool. Porting it to perl and turning it into a server-side tool would have two benefits: - it could be used with JS turned off - a bookmarklet could be created to provide QuickSearch functionality - the ugly hack with the hardcoded keywords could be removed It would make development a little harder because you'd have to change the server, or setup your own, each time you want to test a little change, but I think it's worth it.
Keywords: helpwanted
Target Milestone: --- → Future
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: Bugzilla 2.11 → 2.11
See also bug 100490, incorrect error message ("bogus bug ID") when trying to use quicksearch with javascript disabled.
Opera 5.12 with Javascript enabled shows an error message with a link to this page.
So does Mozilla on Solaris, build 2001121110. I have JavaScript enabled.
Same on Mozilla build 2001122106, Win 2k. I also have JavaScript enabled and keep getting directed back to this page from the message stating "You need to enable JavaScript." Did not have this issue previous to this build.
examining the source to see why this happens ... i am quite interested to fix this ...
If this happens to you, please look at your JavaScript console or whatever it is where your browser provides JS errors, and copy any errors related to the problem into this bug. Thanks.
Blocks: 72947
If this is of any use to anyone, I have ported the javascript to perl. It still uses the hard coded keywords, cos I don't have access to bugzilla to work out how to automatically get them I am still fine-tuning the perl (at the moment it is a straight port), but if anyone is interested in having a look at it, see http://mozilla.flowerday.cx/quicksearch.cgi
Hey, cool. I guess this won't make 2.16, but let's hope for early 2.18. Crispin: feel free to take the bug (reassign it to you) and remove the helpwanted keyword if you are willing to respond to reviews. I will certainly review it, some time during the next weeks. When I'm done, someone with more experience in reviewing perl code needs to do a second pass. When I have this installed locally, what do I need to change to make it submit the queries to a different installation, e.g. http://bugzilla.mozilla.org/ ? (Just for testing.)
Target Milestone: Future → Bugzilla 2.18
By the way, which version of quicksearch.js is this based upon? As far as I know, the current version is 1.9, and it does not contain a reference to "document.f.id" any more.
This is based on the version that is currently on http://bugzilla.mozilla.org . Over the next couple of days, ill have a go at checking out the current version from CVS and port that. The base url for bugzilla is passed into the QuickSearch::QuickSearch() function, along with the text entered. That function can be used as follows my ( $url, $error ) = QuickSearch( "http://bugzilla.mozilla.org/", $querytext ); if ( $url ) { redirect_to( $url ); } else { print "An error occured: $error\n"; } I am willing to own this bug, but don't have enough privileges to change it.
-> Crispin :)
Assignee: nobody → cflowerday
Keywords: helpwanted
Crispin - I've given you privileges to edit bugs, including this one. However, if you are taking on this bug, you need to make sure you've read the hacking parts of the Bugzilla Guide (see http://www.bugzilla.org for a link), read some of our code to check our style, and probably run a design past justdave@syndicomm.com, the Bugzilla module owner. All these things will save you trouble further down the line :-) Gerv
Ok, I have started looking at this in depth now. As I see it there are 2 different ways I could implement the quicksearch. 1) Make it completely self contained, still requiring the configuration of things like the keywords and resolutions. This has the advantage of being faster from the users point of view, but the disadvantage of requiring the configuration 2) Completely integrate with bugzilla, automatically getting the keywords and resolutions etc. Disadvantage the loading of all the extra perl module takes time . Advantage of course is the need for less configuaration. (the product and component exceptions, and the statuses that class as open still require configuring) The relative times are 0.6 and 1.8 seconds respectively on a P200mmx. As for implementation I was thinking of having a QuickSearch perl package, and, exactly like the current javascript implementation having 2 different functions into it: QuickSearch(), and LoadQuery() both would take 2 or 3 arguments, the bugzilla base href, the search term and (optionally)whether to include the long description in the search. The return values would be a url (to redirect to) and an error (if the url was undef). The actual searching would just be a straight port from javascript to perl (making as much use of perl's features as possible). Then there would be a quicksearch.cgi (or similar) that basically wraps the calls up. Any comments are greatly appreciated as this is my first work on bugzilla, also any thoughts on whether it is better to have tight integration or speed?
Crispin: I like #2 - integrating it with Bugzilla. The less configuration and upkeep, the better.
Please do full integration. This is bug #99955, and we will definitely have to do it for 2.18 as it blocks bug #94534.
Yes, quicksearch should get the keywords etc. like all the other perl code does. I think it's a good idea to have a QuickSearch.pm perl module, and a tiny quicksearch.cgi wrapper. Speed is not so much an issue, I think. One lucky day, quicksearch can be changed to not generate a redirection url, but instead call the appropriate buglist or query code directly, without the overhead of starting all the cgi machinery a second time. But we should have the port first, then think about optimizations.
OK, full integration it is (my preference anyway). My current working source is at http://mozilla.flowerday.cx. From there you can download the source I am currently working on (so may occasionally be broken). It should just drop into an existing bugzilla installation. Things I would like to know: - is there configuration currently which would give me the statuses that mark bugs as being open (as opposed to resolved) - is there anyway to remove the need for configuration of the platforms (they seem to have a special meaning in the quicksearch), the product exception list and the component exceptions. Also I wonder if someone would just give the code a brief once over just to check on style.
Status: NEW → ASSIGNED
> - is there configuration currently which would give me the statuses that mark > bugs as being open (as opposed to resolved) In globals.pl, there are: sub IsOpenedState {...} sub OpenStates {...} > - is there anyway to remove the need for configuration of the platforms (they > seem to have a special meaning in the quicksearch), I implemented them because I thought it might be a benefit to easily restrict searches to "pc"-only, "mac"-only, or "sun"-only bugs etc. But I almost never use this field in bugzilla queries, and I think I never used it in a QuickSearch query at all. I invented it before the platform:mac notation was developed, so I think the best solution is to drop support for this completely, and think about a shorter field alias for "platform:", maybe "pl:"? There are few cases where this field has useful information on b.m.o. If you still wanted to support it, you may be able to use $::legal_status or something. But I think it's probably better to drop it. Maybe the same applies to OS. > the product exception list and the component exceptions. No way. Well, practically no way. They depend on your product and component names. They were assembled for bugzilla.mozilla.org when they were found to be necessary: Searching Products and Components for the entered substring does the right thing 90-99% of the time, but some words/substrings that are plausible to be part of your query unfortunately occur in a name of a product or component that doesn't have _anything_ to do with what you are looking for, like "row" in "Browser", or "hang" in "Bugzilla: Component and Keyword changes". I added them when I had attempted a query that returned way too many results, because of such an occurrence of a search term in a product or component name. This is a manual process for each installation. I think automating this process requires artificial intelligence.
I have installed the three files QuickSearch.pm, LocalConfig.pm, quicksearch.cgi and after changing /usr/bin/perl to my path in quicksearch.cgi, it runs, but it always seems to redirect to %baseurl% with "?" appended. No idea why (yet).
Ok, found it. Changing the <form action="?"... to <form action="quicksearch.cgi" method="POST"> made it work.
Yeah, sorry about that, I have changed it. Interestingly it worked fine here (galeon 1.1.3/moz 0.9.8). Thanks for the info - Ill alter some of that stuff over the next couple of days.
I'm impressed. Most of the time, it does what it should. Sometimes it gets into a state where only the baseurl with a "?" appended is shown, and then going back doesn't recover it; I have to press reload or something. But in general, all things I tried do what they should.
Dear Boris, I just read thoroughly your note. I have already sent the info requested back to you in email form. Sorry for any inconvenience. http://www.amazon.com/exec/obidos/search-handle-form/103-1347666-3958232 is the exact web site I went to. The exact error message i received is: Browser Bug? Attention: There appears to be a bug in the web browser you are currently using. Here are some ways to get around the problem: 1. return to the page you were previously on 2. To check out, ...(followed by instructions on how to check out). Your web browser is Mozilla/4.0 (compatible;MSIE 5.0; AOL 7.0; Windows 98; DigExt). That was the end of the message. I have AOL 7.0, and Windows 98, 2nd Ed. I have looked in the help menu to try to find out the answer to the exact Mozilla build I am using, but am having no luck finding this. Got any tips? Thank you, Bonnie
The previous comment was meant for bug 128768.
THis might need to be synchronised with the work over at bug #72837.
Blocks: 99955
Ignore my last comment, it was dumb. How is this going? Given it blocks bug #94534, which in turn blocks various other stuff, it would be cool to get this in fairly quickly after 2.16 is released.
My preference would be to fixup the issues blocking a checkin, and get it into the tree as soon as possible, and then do further bugfixing there. Since this is an add-on, it can't break anything, as long as we don't remove the old quicksearch. Once everybody is convinced that it works sufficiently well, we can switch the default, and then gradually drop support for the old way, if necessary. So IMO the main question is what blocks checking this into the tree. There are several possible issues where I'm not an expert, maybe someone else can jump in: - Is the license header acceptable as-is? I'm guilty of the old one in the javascript version, so maybe someone more familiar with the license templates should answer this question. - Do we insist that it needs to use templates for every little output that is generated, even if it's debug-only, or just very few lines? If this is required before it can be checked in, then this needs some more work, discussion on template filenames, the appropriate directories, etc. Alternatively, the debug output could be removed from the code, but I'd rather not do that if at all possible. - Someone familiar with the style guide should have a quick look over the code and say whether something needs to be changed. As for code quality, I think this is a good translation of my javascript code, probably better. So based on my glancing over parts of the code and my testing mentioned in comment 22, I am happy to give it r=afranke if that's the only thing needed for checkin. Of course, if it's allowed to go in now, we need to test again before the actual checkin. The reason for checking it in now, before all kinds of rewrites, improvements, and fixes, is that now it's quite close to the javascript version, so we won't lose any history. If we don't check it in now but instead do all kinds of fixups outside of cvs, then it's harder to keep the javascript version in sync with the fixes. (I think this is a useful thing to maintain the javascript version for a while because it is basically server-independent, so anyone can hack their local javascript quicksearch and use it with bugzilla.mozilla.org; you can't do this with server-side quicksearch, instead you'd have to wait for b.m.o to upgrade.)
I have not had a chance to hack on this for quite some time now, but I believe that it is in a state where it could be checked in. I also have a program that I started that tests various functionlity inside the QuickSearch.pm module, although the tests that I wrote do not currently test all the functionlity. As for things blocking a check-in, mentioned in comment 27, - Licensing, I have not objections to changing the license header. - templates, I have no knowledge of templates, so will leave that desicion to other people - As for code quality, I would appreciate feed-back from people, including better ways of doing things / style. If anyone wants to take over the bug, its yours, I dont really have the time to give the module the time it deserves.
Blocks: 102618
Keywords: helpwanted
When will this be fixed? I can't wait make QuickSearch into a bookmarklet.
My build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020610 with Javascript enabled cannot quicksearch (I get the black-on-red error message).
Recent versions of Chimera (CVS build from today, as well as 0.27 release) get the red box & the pointer to this bug when searching for "chimera" from the main bugzilla page. Works fine, though, on Mac OS X Mozilla 1.0 release.
Same thing happens with the term "mfcembed" (or any term) when searching from MFCEmbed.
******************************************************************************* ******************************************************************************* NOTE FOR PEOPLE WHO GOT A "The bug ID ... is invalid" ERROR =========================================================== 1. Please not that currently the bug lookup text box in the footer does *not* have quicksearch functionality. This means that you can type a single bug id in there, either a bug number (e.g. "12345") or an alias (e.g. "bmo-regressions"). If you enter a non-existing alias, you will get this error. 2. If you get this error after submitting a search on the b.m.o front page in the quicksearch text box, and you have javascript enabled, then please paste any relevant javascript error messages (exceptions) from your javascript console into this bug, or, if none exist, say so explicitly in your comment. ******************************************************************************* *******************************************************************************
Whiteboard: PLEASE READ COMMENT #33 BEFORE POSTING COMMENTS
As per comment #33, I have JavaScript enabled and am still getting the error message on the b.m.o homepage. Here is the text from the JavaScript Console: Error: input has no properties Source File: http://bugzilla.mozilla.org/quicksearch.js Line: 704
Sean, this worksforme with build 2002070321 (as well as all other builds I used) on Linux, tested by quicksearching for mfcembed . What platform / build are you using? If you see this, can you help debug a bit? Line 704 of quicksearch.js is the last line of this fragment: function QuickSearch (input) { //remove leading and trailing whitespace input = input.replace(/^[\s]+/,"").replace(/[\s]+$/,""); so either the input parameter is undefined, or it doesn't like the "input=input.replace(...)..." line. You could find out by inserting an alert(input); at the beginning of the function, and if that value is ok, trying to use a different name for the parameter: function QuickSearch (theinput) { //remove leading and trailing whitespace input = theinput.replace(/^[\s]+/,"").replace(/[\s]+$/,""); The QuickSearch function is called from the b.m.o frontpage like this: <script language="JavaScript" src="localconfig.js"></script> <script language="JavaScript" src="quicksearch.js"></script> <form name="f" action="show_bug.cgi" method="get" onsubmit="QuickSearch(f.id.value); return false;"> <hr> Enter a bug # or some search terms:<br> <input type="text" name="id"> <input type="submit" value="Show"> <a href="quicksearch.html">[Help]</a> <hr> </form> You can debug this by downloading http://bugzilla.mozilla.org/quicksearch.js and http://bugzilla.mozilla.org/localconfig.js and putting them up on a local web server together with an html file that contains the above fragment (or just use http://www.ags.uni-sb.de/~afranke/mozilla/quicksearch.html ). By inserting alert(f.id.value); in the onsubmit handler you should be able to find out whether the text field content is found by the javascript. Eventually you may be able to find out where things go wrong. Since I can't reproduce this problem, I need this info so that I can fix it.
Keywords: patch, review
Well I have Javascript enabled but it thinks I don't. Great. :-( . BUILD: 2002053012
http://bugzilla.mozilla.org/show_bug.cgi?id=070907 The bug ID 070907 is invalid (i.e. it is neither a bug ID nor an alias to a bug ID). If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907. I'm getting tired of running into this error page. the following need to be fixed: 1. the page needs to check to see if there was a referrer, if there wasn't one it should not mention QuickSearch 2. the specific method i'm using to get here (0xxxx) needs to be accepted as valid. No i have not read this bug in the past 5 minutes. I have read this bug in the past, but given that i'm still seeing it, and that I'm having trouble browsing due to memory constraints I will assert that what i see are unaddressed bugs that just plain need to be fixed.
FWIW, this affects Chimera, right now. visiting http://bugzilla.mozilla.org/ in Chimera 0.4 doesn't allow you to use QuickSearch by default.
Comment #33 have a typo error of the word, "note" with is displayed as "not".
My cgi hit counter does not work. Works fine with Internet Explorer.
See bug 159451 pertaining to comment 38.
Blocks: 154004
As per comment 33, here are 2 errors I get in the JS Console after entering search terms on the bmo website: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///E:/Internet/mozilla/components/nsSidebar.js :: nsSidebar :: line 65" data: no] Source File: file:///E:/Internet/mozilla/components/nsSidebar.js Line: 65 and Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///E:/Internet/mozilla/components/nsSidebar.js :: nsSidebar :: line 65" data: no]
Adage to my comment 42 above: I'm on Win2k, and seeing this error on build ID 2002091508
It would be appreciated if this bug could be fixed asap, as us poor ignorant users, in our ignorance, try to help by posting bugs, and so keep copping flack, because, of course, all bugs were discovered long before we downloaded and unpacked the current nightly, AND WE WERE NOT TOLD!
Having this problem with build 2002092804. Never saw it before.
Got the following error message: Error: uncaught exception: [Exception... "Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIDOMWindowInternal.sidebar]" nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)" location: "JS frame :: http://bugzilla.mozilla.org/quicksearch.js :: go_to :: line 49" data: no] This is on a fresh install (including fresh profile) of build 2002093010 on Win2K. Javascript is of course enabled, though popups are blocked.
re: all the recent comments about how quicksearch stopped working in recent mozilla builds, this is a different problem than this bug purports to be about. i created bug 172475 for this new issue. imo, bug 70907 should continue to be an enhancement reguest to replace the javascript quicksearch entirely, not fix bugs in it.
Hmm, I have just installed Mozilla 1.2b Now I cannot search for bugs in bugzilla. It says in a big red box now whenever I search: The bug number WHATEVER is invalid (it is neither a bug number nor an alias to a bug number). If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907. I checked preferences and javascript is enabled. Any ideas what is going on? I'll have to reinstall Mozilla 1.1 to get it to work. The problem doesn't happen in IE.
Exactly the same problem (comment #48), with WinXP... I have to use the Query page.
same problem with win2000
I'm using Mozilla 2002101612 on Windows XP and searched for "ALL soemthing else", the result was a link to this page, and the following message in the JS console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIDOMWindowInternal.sidebar]" nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)" location: "JS frame :: http://bugzilla.mozilla.org/quicksearch.js :: go_to :: line 49" data: no]
Error: uncaught exception: [Exception... "Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIDOMWindowInternal.sidebar]" nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)" location: "JS frame :: http://bugzilla.mozilla.org/quicksearch.js :: go_to :: line 49" data: no]
Stop spamming this bug, guys. This bug is about making QuickSearch server-side, as the summary quite clearly suggests. Also, this bug is even more clearly marked as "enhancement". What you guys are complaining abotu aren't enhancements, but issues. Known issues, for sure. See comment 33 and comment 47. I'm certain it's one of them.
I also have this problem when using Chimera (one of the nightly builds beyond the 0.5 release)... ah yes, the user agent is reporting: Gecko/20021020 Chimera/0.5+. Anyway, I only mention this because Chimera hasn't been mentioned here in a comment in a while.
Build ID: 2002101612 Platform: Windows 2000 Service Pack 2 I did have this problem. Default Mozilla User was able to use QuickSearch. Created a user profile. Deleted Default Profile AND the files. User created above was not able to search using Quicksearch. When I tried to replicate this by: Uninstalling Mozilla Deleting the Mozilla profile files for the user created above Reinstalling Mozilla 1.2b Default Mozilla User was able to use QuickSearch Created a user profile. Deleted Default Profile AND the files. User WAS now able to search using Quicksearch. There was a Javascript error similar to the others listed earlier. Unfortunately, I did not copy it at the time so cannot give the exact error.
test a bug
Pheonix do not work with PHP Pages, what can I do? Please Help me, please! gregstyle2@yahoo.de thanks!!!!!!!!!!!!!!!!!!!!!!1
Re: comment #33: Can someone explain why entering a term like "mfcembed" throws the "Invalid Bug ID" page when searching in Gecko-based browsers like MFCEmbed and K-Meleon (using Mozilla 1.2beta code) but when I do the same search in Internet Explorer 6, Bugzilla merrily churns out a list of "mfcembed" specific bugs? I know this isn't specific to this bug but someone needs to work on the error message as this is the only place you are directed when you have problems.
Get error telling me to submit a comment to this bug: attempting to search for existing bug before submitting a new one led to "invalid bug id" message. phoenix 0.5; win98se javascript enabled, blocked popup windows. Javascript exceptions: Error: syntax error Source File: http://bugzilla.mozilla.org/localconfig.js Line: 1 Source Code: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> Error: syntax error Source File: http://bugzilla.mozilla.org/localconfig.js Line: 1 Source Code: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> Error: bugzilla is not defined Source File: http://bugzilla.mozilla.org/quicksearch.js Line: 724
galeon.sf.net 1.2.7 on mozilla 1.2.1 rh8 xft, linux rh8 with rawhide updated. JS enabled, console show me; error: syntax error In http://bugzilla.mozilla.org/localconfig.js, Line 1, <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> error: bugzilla is not defined In http://bugzilla.mozilla.org/quicksearch.js, Line 724,
'bugzilla is not defined' is bug 153874
I've got the Invalid Bug ID when trying to find bug on the guided bug report. Error: syntax error Source File: http://bugzilla.mozilla.org/localconfig.js Line: 1 Source Code: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> Error: bugzilla is not defined Source File: http://bugzilla.mozilla.org/quicksearch.js Line: 724 Contents of http://bugzilla.mozilla.org/localconfig.js: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> You don't have permission to access /localconfig.js on this server.<p> <hr> <address>Apache/1.3.26 Server at bugzilla.mozilla.org Port 80</address> </body></html> I seems to be a misconfiguration of the web server.
i entered this to search for bug reports "personal toolbar expand context". I am using build id 2002122108. This build does not have Moailla Mail.news, composer or chatzilla. It just has the browser. ALso the security options have been taken out...such as cookie/image manager etc.
Using Chimera, Build 2002122004, Mac OS X/10.2.3; JavaScript Enabled Attempt to use the Quick Search using alpha terms from "front page" query failed and produced the following message: " The 'bug number' is invalid. It is neither a bug number nor an alias to a bug number. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907." No Java Console available with this software, unless there is a secret method you can tell me about. Entering a numeric search term yields normal function.
Chimera 0.6 Build 2003010706 in Mac OS X 10.2.3. I cannot use Chimera 0.6 to search Buzilla as it reports "The 'bug number' is invalid. It is neither a bug number nor an alias to a bug number. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907." just like what Mark Lee Scoble, Jr. is experiencing. I still have to use Mozilla Navigator for Bugzilla.
Can't use keywords in Bugzilla with Mozilla ID2003012508/WinXP. All JavaScript was enabled. (Moz 1.2.1 worked fine) (ps blame http://bugzilla.mozilla.org/show_bug.cgi?id=bookmarks for redirecting me to this bug) ---------error message copy/paste from the JavaScript console-------- Error: uncaught exception: [Exception... "Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIDOMWindowInternal.sidebar]" nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)" location: "JS frame :: http://bugzilla.mozilla.org/quicksearch.js :: go_to :: line 49" data: no] ---------end of error message----------------------------------------
Is someone ever going to get around to fixing the error message that clearly has nothing to do with this bug? Why don't you include an explanation of why the message is appearing and providing an alternative means to search, like the full query page? It should be sooner rather than latest as this "bug" is getting widespread attention here: http://www.zeldman.com/daily/0203b.shtml#aboutswitch and it makes Mozilla and Bugzilla look bad.
sure could use it!
I am unable to access anything further, after I access a website. The browser just continues searching, but not finding.
I DO have JavaScript enabled and it still doesn't work in Camino 2003031208
ok, this has sufficiently annoyed me. From the javascript error mentioned it would appear that the sidebar is the problem. MFCembed and Chimera fail because they don't provide a sidebar implementation, while IE has no problem since sidebar is simply undefined. I would think replacing the go_to function in http://bugzilla.mozilla.org/quicksearch.js with the following might fix the problem. function go_to (url) { try { if ( typeof sidebar != "undefined" && sidebar == 1 ) { load_relative_url(url); return; } } catch (ex) { } document.location.href = url; } ccing some bugzilla people.
Build 2003040308 / XP with the latest Sun J2SE 1.4.2 beta. Bugzilla tells me I don't have JavaScript in my browser, and Mozilla's JavaScript Console is giving me the error "QuickSearch is not defined." Is it the beta of the latest J2SE at fault, or is it Mozilla?
I should mention (quickly, before I'm yelled at here) that I've read comment 33 and I've tried using both the main b.m.o query and the one from the File A Bug page. I'm just about to revert to J2SE 1.4.1_2 to see if it really is this that's causing the problem.
It is indeed J2SE 1.4.2 beta that's the culprit here - don't install it! (And it's bug 200563 that's dealing with it.)
Re comment 71: That shouldn't be necessary. sidebar is a variable that is set to 1 in the sidebar xul. If typeof sidebar == "undefined" then the variable has not been set and the else clause is executed. But that's not really this bug. This bug is about porting QuickSearch to Perl from JavaScript, not about current QS JS errors. If anyone can provide steps to reproduce the JS errors, file a separate bug (I don't know why b.m.o's error message says to spam this bug). cflowerday@zeus.com: Is your code on http://mozilla.flowerday.cx complete and still valid? If so I can test it. I'd like to see it checked in soon if it's good and if it's working. Once it's in I'll start working on converting the templates that use the current JS code (the templates for sidebar.xul and enter_bug.cgi/guided afaik) to work with the Perl version.
Basically the code is complete, it needs someone to go over and ensure the style is ok, but apart from that, all the functionality of the javascript one is there. Apart from someone giving a quick check, I believe that it is read to go.
Attached file This is SPAM (obsolete) —
76887878787u87u878777787
Is that attachment (121427) spam? Looks like an MS Word document...
Comment on attachment 121427 [details] This is SPAM Indeed it is spam
Attachment #121427 - Attachment description: y78789787787 → This is SPAM
Attachment #121427 - Attachment filename: 200321411425799828.doc → spam.txt
Attachment #121427 - Attachment is obsolete: true
Attachment #121427 - Attachment mime type: text/html → text/plain
How annoying. This is Konqueror 3.1.2 and I *do* have JS enabled.
Attached file Diff of change to main page (obsolete) —
(Referring to problem of using quicksearch in Bugzilla 2.16.3, even though JavaScript is enabled. See also Comment #33 and Comment #34.) Yes, I too have started having problems using the QuickSearch function (Win2k, Internet Explorer 6.0p1) in Bugzilla 2.16.3, although JavaScript is enabled. Reading Comment #34, I sat down and had a look at the JavaScript for the main page. Turns out the parameter to the call to the quicksearch functions is lacking, making the argument in the quicksearch function undefined. Me, I patched this by simply changing the line: <form name="f" action="show_bug.cgi" method="get" onsubmit="QuickSearch(); return false;"> to : <form name="f" action="show_bug.cgi" method="get" onsubmit="QuickSearch(f.id.value); return false;"> (line numbers 83-84 in index.html. See appended diff.)
When I enter "Solaris 9" (with or w/o quotes) this message appears: The 'bug number' is invalid. It is neither a bug number nor an alias to a bug number. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907. JavaScript Error: http://bugzilla.mozilla.org/quicksearch.js, line 462: invalid case expression JavaScript Error: http://bugzilla.mozilla.org/quicksearch.js, line 462: invalid case expression JavaScript Error: http://bugzilla.mozilla.org/quicksearch.html, line 27: QuickSearch is not defined. JavaScript Error: http://bugzilla.mozilla.org/show_bug.cgi?id=70907, line 580: document.getElementsByTagName is not a function. JavaScript Error: http://bugzilla.mozilla.org/show_bug.cgi?id=70907, line 580: document.getElementsByTagName is not a function. JavaScript Error: http://bugzilla.mozilla.org/show_bug.cgi?id=70907, line 580: document.getElementsByTagName is not a function.
In the bugzilla.redhat.com page, there's a box that says: Simple Search: Enter a bug # or some search terms: I entered "Samba" as the search term (according to the instructions) and the following error was the result: The 'bug number' is invalid. It is neither a bug number nor an alias to a bug number. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907. Now, the issue here is that I entered, correctly, a search term, and your search engine ignored it, expecting a bug number only. PLEASE either fix this so search terms (most useful) are accepted, or change the description so that you MUST use bug numbers (and how, pray tell, do we find those out without being able to search for terms)?. Regards, HiltonT
Hilton: I would suggest you report that to redhat... they use a customized template set that they created themselves, and it might be wired wrong. I would have them confirm that first.
First, I reproduced this bug 70907, comment 62. I went further, when I changed the permission, I got "Internal server error ..." instead. I got this Apache ScriptAlias (not Alias) configuration in my httpd.conf: ---- cut ---- ScriptAlias /bugzilla/cgi-bin "/bugzilla/full/directory/path/" <Directory "/bugzilla/full/directory/path"> AllowOverride None Options None Order allow,deny Allow from all </Directory> ---- cut ---- This setting will not read or execute *.js files in that directory. Since I already have an actual directory: $APACHE/htdocs/bugzilla/ I copied both localconfig.js and quicksearch.js to this directory instead, and changed data/template/en/default/index.template.tmp so the actual lines in index.html look like below (copied quicksearch.html too), now this *bug* is no longer reproduced: -------- cut -------- <form name="f" action="show_bug.cgi" method="get" onsubmit="QuickSearch(f.id.value); return false;"> <p> Enter a bug # or some search terms:<br> <input type="text" name="id"> <input type="submit" value="Show"> <a href="/bugzilla/quicksearch.html">[Help]</a> </p> </form> </td> <td align="right"><img src="/icons/ant.jpg" width="329" height="220" border="2" alt="ant.jpg [8.5k]"></td> </tr></table> <script type="text/javascript" language="JavaScript" src="/bugzilla/localconfig.js"></script> <script type="text/javascript" language="JavaScript" src="/bugzilla/quicksearch.js"></script> -------- cut -------- So before the perl version is available, this should be the *work around* for this *bug*, for anyone that has the same Apache configuration. The other work around then is of course to change the directory setting for bugzilla/cgi-bin above and restart httpd. This *work around* will work both on Netscape and IE or other browsers, this is server side problem to me.
Re Comment #85: Bugzilla is not set up to run within a cgi-bin (or a directory set up using ScriptAlias). This bug is not the only manifestation of that. There are many other static files (.html, .css, .jpg, etc) that will not work if your are trying to put Bugzilla in a directory defined by ScriptAlias.
Either Perl or PHP. JavaScript is lame.
If the "Find" button is clicked when the input field is left blank, a full error message is given. I suggest it would be more appropriate to say something like "Please enter a value" rather that start talking about scary things like enabling Javascript. Yes I know it is stupid not to read the instructions before clicking with the mouse, but in the real world that is what happens - please cope gracefully.
I think the message I got was not very informative. I tried using the bugzilla at http://bugs.gentoo.org/ when I got the big message on red background. I figure it is a problem with gentoo's bugzilla and not bugzilla itself (fetching quicksearch.js gives 403), but I have a small suggestion. Could the message be made to mention explicitly that the link to bug 70907 is an *external* link? I browsed the comments here, and it took me quite some time to figure that I am looking at bugzilla.mozilla.org and not bugs.gentoo.org.
Caught with Mozilla Firebird - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031114 Firebird/0.7+ . This is the 1st error on JS console. Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///D:/USR/MOZ_FB/components/nsSidebar.js :: nsSidebar :: line 67" data: no] Source File: file:///D:/USR/MOZ_FB/components/nsSidebar.js Line: 67 I just hope that this is useful and that I'm not spamming ...
Mozilla 1.3 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 Slackware Linux 9.0 GTK 2.2.1 KDE 3.1 Kernel 2.4.20 On Openbox Bugzilla after trying a quicksearch get error that JS isn't enabled...which it is. charris@vectec.net
Slackware Linux 9.1 KDE 3.1.3 Kernel 2.4.22 I went to the main page and entered KDE clock (because of a Mozilla clock bug under KDE), and received a pointer to this bug. I have Javascript enabled, yet I get this error. Hmm!
I get that when submitting a bug, this is ridiculuous, AND JAVASCRIPT is enabled, tried with Mozilla 1.5 and 1.6 on Linux... Oh well...
On Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031130 Firebird I have js enabled. I received the invalid bug error not after a search, but after attempting to submit a comment to a bug that was "next in my bug list". The URL was http://bugzilla.mozilla.org/process_bug.cgi. The "next" bug was 186797 (though I doubt the bug # had anything to do w/ it). I do not see the js errors that other have reported. If this is spam (comment #53), where should I report the buggy behavior I've experienced? Neither bug 172475 or bug 171441 are appropriate, as mentioned in comment #47. On a side note, going back and resubmitting my comment went through just fine(!?). This is the only time I've ever had that error...is there a separate bugzilla bug for this b.m.o. error message?
I'm sorry I don't really have the time to tidy up the loose ends of the code. The code I wrote ages ago is available for anyone that wants to finish the server-side port.
Assignee: mozilla → justdave
Status: ASSIGNED → NEW
Well, after attempting a quick search from b.m.o. home page & going back to try another one, these were found in the js console (order last>first): Error: [Exception... "'Permission denied to get property XULElement.selectedIndex' when calling method: [nsIAutoCompletePopup::selectedIndex]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: http://bugzilla.mozilla.org/ :: <TOP_LEVEL> :: line 125" data: no] Source File: http://bugzilla.mozilla.org/ Line: 125 Warning: reference to undefined property document.forms Source File: http://bugzilla.mozilla.org/ Line: 125 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031130 Firebird
Assignee: justdave → nobody
ljkljkljklkjlkjl
Flags: approval?
there's no patch to approve here yet....
Flags: approval?
Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
my computer went to a deep slow - when i access through internet explorer this comes up 207.177.40.144 which takes me to something caliled www.perfectnav.com Ihave had problems for 2 and a half years most are hyjacking my registration numbder and taking controle of my system these attacks have been beyond the capabilitys of adaware
That isn't a bug on the site, but something wrong with your system. Back up all your data, reinstall the OS, and get a firewall program like Sygate that can detect when unauthorized programs connect to the internet (although that might not help for software that hijacks IE and possibly modifies its binaries).
Just upgraded to firefox 0.8-r2 and now I can't use quuicksearch; the error pointed me to this bug. I have javascript enabled in my browser. My JavaScript console has an error saying "Error: QuickSearch is not defined"
Error message: Invalid rpm package kdelibs-3.0.5a-0.73.2.src.rpm requested Error class code: 17 Error class info: file not found
Error message: Invalid rpm package kdelibs-3.0.5a-0.73.2.src.rpm requested Error class code: 17 Error class info: file not found
My browser locks up when I click on download manager history, after I do this a little time later the computer ask to end task, and closes the browser, while this is going on my CPU runs at 100% I have uninstalled the browser several times to no avail. I have Mozilla Firefox.
dsds asdss sdrtrtrtr ererer ererere ererere ererererer rereee
Search for words does not work (bug numbers work), using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040601 Firefox/0.8.0+. JavaScript Console gives these two errors: 1. Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSidebar.js :: nsSidebar :: line 67" data: no] Source File: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSidebar.js Line: 67 2. Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSidebar.js :: nsSidebar :: line 67" data: no]
I can confirm the problem in Firefox branch build from 20040529, I get the error directing me to this bug. The javascript console contains the following two errors: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSidebar.js :: nsSidebar :: line 67" data: no] Source File: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSidebar.js Line: 67 Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSidebar.js :: nsSidebar :: line 67" data: no]
(In reply to comment #108) Bug 245051 comment 3 at a quick glance. In any case it's been fixed, and it's not really relevant to this bug because it's clearly an application failure, not a Bugzilla failure.
I'm using konqueror 3.2.2. I have javascript enabled. The bugzilla site at gentoo.org is exhibiting this bug when I try and search and told me to add a note here. I am able to use konqueror to search other bugzilla installations, like the one at kde.org.
(In reply to comment #110) > I'm using konqueror 3.2.2. I have javascript enabled. The bugzilla site at > gentoo.org is exhibiting this bug when I try and search and told me to add a > note here. I am able to use konqueror to search other bugzilla installations, > like the one at kde.org. Same problem here with Firefox-0.8-r3. The output from my javascipt console is: "Error: QuickSearch is not defined" when I execute the search. I also get the following erro when I first visit the search page: "Error: unterminated string literal Source File: http://bugs.gentoo.org/quicksearch.js Line: 628, Column: 25 Source Code: '<body><script><!--" However I think this is unrelated.
When viewing on a forum specifically Lockergnome my graphic picture in my signature does not view properly instead it leaves a tripod icon, but on IE it will generate the graphical picture on the forum, need info regarding this error.
eternity739@earthlink.net: info: your problem has nothing to do with anything in this product (Bugzilla). if you're using mozilla, you might ask mozillazine.
I get the following error (with the Mozilla I compiled last night -- I don't know if this is related): The 'bug number' is invalid. It is neither a bug number nor an alias to a bug number. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907. No JS error in the console, just: Document http://bugzilla.mozilla.org/show_bug.cgi?id=sidebar+empty loaded successfully
Hey, Please help me here. I have taken over 3 days in installing Bugzilla on XP. owever i am unable to add a bug, and i am repeatedly thrown the above mentioned error, on giving submit on add bug page. I have added a product and veriosn for this project exist. Awaiting your help soon Thanks and Regards Ankur Shukla 91 98860 63018
Hey, Please help me here. I have taken over 3 days in installing Bugzilla on XP. owever i am unable to add a bug, and i am repeatedly thrown the above mentioned error, on giving submit on add bug page. I have added a product and veriosn for this project exist. Awaiting your help soon Thanks and Regards Ankur Shukla 91 98860 63018
on: http://bugzilla.mozdev.org/show_bug.cgi?id=CVS Error The bug number is invalid. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, look here. (Javascript is enabled) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Attached patch A try (obsolete) — — Splinter Review
This may need some work yet. But I wanted to put it up for discussion.
Attachment #157507 - Flags: review?
Runtime Error Program C:\program File\DC++\DCPlusPlus.exe This aplication has requested the Runtime to terminate it in an unusual way. please contact the... barney.w@blueyonder.co.uk
Make sure you aren't going through any proxies that block javascript. I had javascript enabled, and was still getting this error page. Then remembered I had privoxy (an ad blocking proxy, among other things) running. When I connected directly to the site everything worked.
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
Dear friends, I arrived here because of an invalid link http://bugzilla.wikipedia.org/show_bug.cgi?id=id%3D661 from [[bugzilla:id=661]]. This reminds me about "parameter integrity checking" I was working some weeks before in order to avoid crashes at my homepage from h@ck€rs traying to find out what will happen if instead an positive intergers parameters like 3.1428, strings, negative numbers, floating numbers as 3,000000000000000000000000000000001 or other parameters nor supposed / suported during development would be entered. If you need more informations please feel free to contact me at reinhardt dot wiewe at lenauschule dot de. Regards Reinhardt
Reinhardt: This is because quicksearch just submits the form as id= when no javascript is enabled. I wonder if we can add some hidden param to the quicksearch forms for now to let show_bug.cgi know the user came from quicksearch. Like this: <form name="f" action="show_bug.cgi" method="get" onsubmit="QuickSearch(f.id.value); return false;"> <input type="hidden" name="quicksearch" value="yes"> <hr> Enter a bug # or some search terms:<br> <input type="text" name="id"> <input type="submit" value="Show"> <a href="quicksearch.html">[Help]</a> <hr> </form> > homepage from h@ck€rs traying to find out what will happen if instead an > positive intergers parameters like 3.1428 buffer overflow techniques and the like? I don't know if that would affect Bugzilla, since it's written in perl. I'm not sure, though. It'd have to be a value that'd mess up the database query to the point it corrupts it.
addendum: If (for now until this bug is fixed) the query to show_bug didn't come from quicksearch (no quicksearch=yes set) then it'd not mention this bug in the error.
help im being maliciasly torn apart by someone who nows what there doing more so then myself this person is keeping me aprisoner in my own browser help ... please
Flags: blocking2.20?
If someone wants to work on this, I asked Crispin for his patch he made some time ago, so here it is, it's probably good starting point.
Help will not always change topics. These are just a few. XML Parsing Error: undefined entity Location: jar:resource:///chrome/help.jar!/locale/en-US/help/firefox_welcome.xhtml Line Number 54, Column 9: <td>&nbsp;</td> --------^ XML Parsing Error: undefined entity Location: jar:resource:///chrome/help.jar!/locale/en-US/help/welcome.xhtml#finding_the_topic_you_want Line Number 94, Column 14:&#345;&#1032;&#32768; -------------^ XML Parsing Error: undefined entity Location: jar:resource:///chrome/help.jar!/locale/en-US/help/using_firebird.xhtml#searching Line Number 569, Column 14:<p>Copyright &copy; 2003-2004 Contributors to the Mozilla Help Viewer Project.</p> -------------^
Attached patch Complete port to perl (obsolete) — — Splinter Review
Full functionality, now in perl.
Assignee: nobody → wurblzap
Attachment #123966 - Attachment is obsolete: true
Attachment #157507 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #157507 - Flags: review?
Attachment #166126 - Flags: review?
Blocks: 269294
No longer blocks: 269294
Depends on: 269294
******************************************************************************* ******************************************************************************* NOTE FOR PEOPLE WHO GOT A "The bug ID ... is invalid" ERROR =========================================================== 1. If the error directed you to post to this bug, your Bugzilla site is running an OLD VERSION of Bugzilla that contains known security bugs. Please encourage them to upgrade. We now have more than enough information to solve this bug, so PLEASE DON'T ADD COMMENTS unless you are testing or reviewing the proposed patch. Thank you. 2. Please note that currently the bug lookup text box in the footer does *not* have quicksearch functionality. This means that you can type a single bug id in there, either a bug number (e.g. "12345") or an alias (e.g. "bmo-regressions"). If you enter something non-numeric which is not currently being used as an alias on any existing bugs, you will get this error. ******************************************************************************* *******************************************************************************
Whiteboard: PLEASE READ COMMENT #33 BEFORE POSTING COMMENTS → #*#*#*# PLEASE READ COMMENT #131 BEFORE POSTING COMMENTS #*#*#*#
WHAT A HICKKKKKKKKKKKUPPPPPPPPPPPPP@!
WHAT A HICKKKKKKKKKKKUPPPPPPPPPPPPP@!
Flags: blocking2.20? → blocking2.20-
(In reply to comment #130) > Complete port to perl Why don't you create a new file quicksearch.cgi instead of adding huge code to buglist.cgi? And why are quicksearch*.html still here?
(In reply to comment #134) Having a quicksearch.cgi would require redirecting to buglist.cgi which I want to avoid. The quicksearch*.html are still here because they still make sense. They are amended to use the perl Quicksearch.
Blocks: 76498
Blocks: 98307, 151555, 174085
Attached patch v1.1 (Fix bitrot) (obsolete) — — Splinter Review
I just directly un-bitrotted this patch so that it will be easier to review. I didn't check anything other than the direct un-bitrotting.
Attachment #166126 - Attachment is obsolete: true
Comment on attachment 174634 [details] [diff] [review] v1.1 (Fix bitrot) OK, first, I'd just like to say that I am *really* impressed with how much work went into this patch. :-) And now, on with the review! :-) >Index: buglist.cgi > ################################################################################ >+# Quicksearch >+################################################################################ OK, first off, most of this does need to go into a module somehow. You could make a QuickSearch.pm, or you could put some of it in as methods in Search.pm. At the least, the huge variables and the configuration stuff needs to go somewhere else. :-) Some of that can go into Bugzilla::Constants, but other parts will probably want to go into the module that you create. I think I'd prefer the "method in Search.pm" method, unless you come up with something that's more architecturally sound. There should be basically a function which takes the $searchstring and returns the real query string. >+ # Forget having done quicksearch: >+ $cgi->delete('quicksearch'); >+ $cgi->delete('run'); Can you explain why we do this? (In the comments.) >+ >+ # Word renamings >+ my %mappings = ("status" => "bug_status", >+ "resolution" => "resolution", # no change >+ "platform" => "rep_platform", > s[nip] >+ "attachmentmimetype" => "attachments.mimetype", >+ "attachmimetype" => "attachments.mimetype"); Can *any* of this be gotten out of fielddefs, or do we have to define it all manually here? I don't want to have to maintain this list when the schema changes. >+ # We might want to put this into localconfig or somewhere This part can almost definitely go in Bugzilla::Constants or Bugzilla::Config. >+ if ($searchstring =~ m/^[0-9,\s]*$/) { >+ # Bug number(s) only >+ >+ # Allow separation by comma or whitespace >+ $searchstring =~ s/[,\s]+/,/g; >+ >+ if (index($searchstring, ',')<$[) { Spacing. And I don't know what $[ is. :-) >+ foreach (@openStates) { >+ $states{$_} = 1; >+ } Use a real variable instead of $_ here, for readability, unless you're going to make that a one-line foreach statement. >+ >+ } else { All of these elses in the boolean chart stuff need a little comment as to what's going on with the logic. >+ if ($cgi->param('load')) { >+ $cgi->delete('load'); >+ print $cgi->redirect(-uri => Param('urlbase') . >+ "query.cgi?" . restoreURIQueryPart()); Quicksearch can actually display the query page, somehow?? >+sub restoreURIQueryPart { >+ my @cgiparamlist; >+ >+ foreach my $paramname ($cgi->param) { >+ next if $paramname eq 'order'; >+ next if $paramname eq 'cmdtype'; >+ foreach ($cgi->param($paramname)) { >+ push(@cgiparamlist, "$paramname=$_"); >+ } >+ } >+ join('&', @cgiparamlist); >+} This needs some comments on its purpose, and perhaps also on its implementation. >+ { >+ name => 'quicksearchmaxwords', >+ desc => 'The maximum number of words usable for QuickSearch. ' . Words? What's a "word" in this case? >Index: skins/standard/global.css Why is this CSS patch in here? (I just don't know.) Everything else looks good. I didn't do a functionality test, but I'll do that in the next review.
Attachment #174634 - Flags: review-
Attachment #166126 - Flags: review?
URL: http://bugs.flowerday.cx/mozilla70907/ → http://landfill.bugzilla.org/bz70907/
Keywords: helpwanted
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
Blocks: 149352
thiis sux
blah blah
Attached patch Patch 1.2 (obsolete) — — Splinter Review
Reworked, introducing quicksearch.cgi. The drawback of this is that we need to do a redirect every time we do a QuickSearch, so the number of httpd and db connects doubles. Other things of note: - localconfig.js and quicksearch.js are gone - quicksearch.html and quicksearchhack.html moved to a page.cgi template - checksetup.pl doesn't allow access to localconfig.js and localconfig.rdf any more - Footer "Find bug # _____" functionality now uses quicksearch - QuickSearch now accepts bug aliases (In reply to comment #137) > OK, first off, most of this does need to go into a module somehow. You could > make a QuickSearch.pm, or you could put some of it in as methods in Search.pm. > At the least, the huge variables and the configuration stuff needs to go > somewhere else. :-) Some of that can go into Bugzilla::Constants, but other > parts will probably want to go into the module that you create. I didn't create a module (yet). For now, there is enough work in the porting :) > >+ # Forget having done quicksearch: > >+ $cgi->delete('quicksearch'); > >+ $cgi->delete('run'); > > Can you explain why we do this? (In the comments.) Done. > >+ # Word renamings > Can *any* of this be gotten out of fielddefs, or do we have to define it all > manually here? I don't want to have to maintain this list when the schema > changes. Maybe in another bug? > >+ # We might want to put this into localconfig or somewhere > > This part can almost definitely go in Bugzilla::Constants or > Bugzilla::Config. True. Let's do it post-checkin. > Spacing. And I don't know what $[ is. :-) From perlvar: "$[: The index of the first element in an array, and of the first character in a substring. Default is 0, but you could theoretically set it to 1 to make Perl behave more like awk (or Fortran) when subscripting and when evaluating the index() and substr() functions." > >+ foreach (@openStates) { > >+ $states{$_} = 1; > >+ } > > Use a real variable instead of $_ here, for readability, unless you're going > to make that a one-line foreach statement. I changed most of these places into a one-line statement. Some (not all) of these one-liners needed to be wrapped though ;) > >+ > >+ } else { > > All of these elses in the boolean chart stuff need a little comment as to > what's going on with the logic. Improved this a little. > Quicksearch can actually display the query page, somehow?? In quicksearchhack.html, there is a Load Query button. > >+sub restoreURIQueryPart { > This needs some comments on its purpose, and perhaps also on its > implementation. It turned out canonicalise_query in CGI.pm does the same. > >+ { > >+ name => 'quicksearchmaxwords', > >+ desc => 'The maximum number of words usable for QuickSearch. ' . > > Words? What's a "word" in this case? Changed it to "terms". > >Index: skins/standard/global.css > > Why is this CSS patch in here? (I just don't know.) The "Find bug # ____" thing in the footer is now a form of its own. The CSS patch takes this change into account.
Attachment #165527 - Attachment is obsolete: true
Attachment #165528 - Attachment is obsolete: true
Attachment #165529 - Attachment is obsolete: true
Attachment #174634 - Attachment is obsolete: true
Attachment #178569 - Flags: review?
Blocks: 221481
Attachment #178569 - Flags: review? → review?(mkanat)
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Comment on attachment 178569 [details] [diff] [review] Patch 1.2 I don't think I'll have time to review this, and I'd also like to have somebody look at it who is more likely to have understood the original JavaScript. :-) My only comment is that I don't really understand why we need a special CGI for this. It seems like any work done to port it to a CGI would have been just as much work as would have been needed to put the code into a module somewhere.
Attachment #178569 - Flags: review?(mkanat) → review?(kiko)
(In reply to comment #141) > My only comment is that I don't really understand why we need a special CGI for > this. It seems like any work done to port it to a CGI would have been just as > much work as would have been needed to put the code into a module somewhere. Patch 166126 didn't introduce a special CGI. I set one up because of comment 134, and I'm more than happy to remove it again because I really don't like the redirects a separate CGI requires. Kiko?
dropping bug 149352 from the blocked bugs list because it has been marked a dupe of bug 269294 which this bug already depends on.
No longer blocks: 149352
the changes to buglist.cgi will break editing a saved search.
Blocks: 152761
Attachment #178569 - Flags: review?(kiko)
Attached patch Patch 2 (obsolete) — — Splinter Review
- Fixed rottage - Introducing Bugzilla/Search/Quicksearch.pm - Small callsite in buglist.cgi I can edit saved searches with this patch, although the buglist.cgi part of the patch hasn't changed much -- Rob, is your comment 144 still an issue?
Attachment #178569 - Attachment is obsolete: true
Attachment #189237 - Flags: review?
Comment on attachment 189237 [details] [diff] [review] Patch 2 1) Runtests fail, on test 1: not ok 86 - Bugzilla/Search/Quicksearch.pm --ERROR # Failed test (t/001compile.t at line 95) Can't locate Bugzilla.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0) at Bugzilla/Search/Quicksearch.pm line 25. BEGIN failed--compilation aborted at Bugzilla/Search/Quicksearch.pm line 25. and on test 2: not ok 86 - Bugzilla/Search/Quicksearch.pm is a module, but has a shebang # Failed test (t/002goodperl.t at line 59) 2) Patch doesn't remove localconfig.js, which seems to be unneeded now. 3) There's still wrong quicksearch help link in using.xml aroung line 730. Maybe add a note there that QuickSearch can also be found in the footer too? 4) What is localconfig.rdf file? I can't find anything that creates or uses it. Bugxula seems to use it for something so I wonder if it really is related to QuickSearch after all. If this is the case, references to it shouldn't be removed.. 5) Nit: config.js.tmpl template seems to still refer to quicksearch.js in a comment around line 22. 6) Tested QuickSearch from sidebar, main page, footer and from the two help pages. Brief tests show that the searching seems to be working. >--- head/Bugzilla/Search/Quicksearch.pm 1970-01-01 01:00:00.000000000 +0100 >+++ patched/Bugzilla/Search/Quicksearch.pm 2005-07-07 21:11:16.041740800 +0200 >+# The Original Code is the Bugzilla Bug Tracking System. >+# Reference to Netscape is missing here. >+# Contributor(s): Marc Schumann <wurblzap@gmail.com> >+# Andreas Franke <afranke@mathweb.org> >+# Stephen Lee <slee@uk.bnsmc.com> >+# C. Begle >+# Jesse Ruderman Nit: These seem to be normally listed from earlier to recent so I would switch them around. >+# Make it harder for us to do dangerous things in Perl. >+use strict; Should there be a package directive too? >+use base qw(Exporter); >+@Bugzilla::User::EXPORT = qw(quicksearch); Err.. Bugzilla::User? Shouldn't that be Bugzilla::Search::QuickSearch? >+# Word renamings >+my %mappings = ("status" => "bug_status", Nit: The first comment is missing. The one that should say "# Status, Resolution, Platform, OS, Priority, Severity". And yes, please, get these incorporated into fielddefs or something to that effect. A follow up bug is fine with me, though. :) >+# We might want to put this into localconfig or somewhere >+my @platforms = ('pc', 'sun', 'macintosh', 'mac'); Erm.. Couldn't these come from the DB instead of this ugly hardcoding? >+ else { >+ # List of bug numbers. >+ $cgi->param('bug_id', $searchstring); >+ $cgi->param('order', 'bugs.bug_id'); >+ } Shouldn't bugidtype be set too? Looks like following translation is missing: // translate " AND "," OR "," NOT " to space,comma,dash This makes the those words to be treated like search terms.. :( >+ # Priority >+ elsif ($word =~ m/^[pP]([1-5]-[1-5])$/) { >+ addChart('priority', 'regexp', >+ "[$1]", $negate); >+ } Where's the other priority matching? Now search terms like p1 doesn't work. :( >--- head/buglist.cgi 2005-07-08 22:03:50.711158400 +0200 >+++ patched/buglist.cgi 2005-07-14 00:55:29.508339200 +0200 >+# We are therefore interested in query fields only, which means we ignore >+# non-query fields like order and cmdtype. >+$vars->{'urlquerypart'} = $cgi->canonicalise_query('order', 'cmdtype'); Nit: Why like? We only ignore those two fields.. >--- head/checksetup.pl 2005-07-14 00:42:22.356470400 +0200 >+++ patched/checksetup.pl 2005-07-14 00:44:06.856734400 +0200 >@@ -995,9 +995,6 @@ > <FilesMatch ^(.*\.pl|.*localconfig.*)$> > deny from all > </FilesMatch> >-<FilesMatch ^(localconfig.js|localconfig.rdf)$> >- allow from all >-</FilesMatch> Nit: This leaves localconfig.js allowance into .htaccess but maybe that's not that big of a deal. There seems to be runtest.sh deny left in there too.. >--- head/defparams.pl 2005-07-05 18:26:04.485940800 +0200 >+++ patched/defparams.pl 2005-07-04 18:07:45.628091200 +0200 >+ name => 'quicksearchmaxterms', >+ desc => q{The maximum number of terms usable for QuickSearch. >+ If this is set to a value greater than 4, QuickSearch allows >+ searching comments.}, For readability, name this quicksearch_max_terms. Maybe the first description line would be more accurate as "The maximum number of search terms allowed in a QuickSearch." ? >--- head/template/en/default/global/useful-links.html.tmpl 2005-07-07 23:22:17.227691200 +0200 >+++ patched/template/en/default/global/useful-links.html.tmpl 2005-07-14 00:39:45.731254400 >+ onsubmit="if (this.quicksearch.value == '') >+ { alert('Please enter search criteria first.'); >+ return false; } return true;"> Hmm.. Would this error be better as "Please enter one or more search terms first."? >--- head/template/en/default/index.html.tmpl 2005-04-12 19:43:20.661561600 +0200 >+++ patched/template/en/default/index.html.tmpl 2005-07-07 20:43:19.881540800 +0200 >+ <form id="show-bug" name="f" action="buglist.cgi" method="get" >+ onsubmit="if (this.quicksearch.value == '') >+ { alert('Please enter search criteria first.'); >+ return false; } return true;"> Ditto. >--- head/template/en/default/global/user-error.html.tmpl 2005-07-07 23:22:18.249160000 +0200 >+++ patched/template/en/default/global/user-error.html.tmpl 2005-07-07 23:23:59.845248000 >+ [% ELSIF error == "quicksearch_max_terms_exceeded" %] >+ [% title = "Too many search terms" %] >+ The database can only cope with so many QuickSearch terms. >+ In order to go easy on it, the number of search terms is limited >+ to [% Param('quicksearchmaxterms') %]. Nit: Hmm.. would this be better if it states the original reason for the limitation too? It was limited because otherwise the query would take forever.. >--- head/template/en/default/pages/quicksearch.html.tmpl 1970-01-01 01:00:00.000000000 +0100 >+++ patched/template/en/default/pages/quicksearch.html.tmpl 2005-07-07 20:47:03.002372800 +0200 >+ # The Original Code is the Bugzilla Bug Tracking System. >+ # >+ # Contributor(s): N.N. Reference to Netscape seems to be missing between those lines. See Bugzilla/DB.pm for the text. >+ onsubmit="if (this.quicksearch.value == '') >+ { alert('Please enter some search criteria first.'); >+ return false; } return true;"> Same wording change here as above. >+ <input type="text" size="40" name="quicksearch"> >+ <input type="submit" name="run" value="Search"> Remove name="run" from the button so it won't appear in the generated URL. Also name the button as Find. >+<h2>Getting Started</h2> Nit: These subtitles look funny because they are now bigger than the main title.. Same goes for the quicksearchhack.html.tmpl template. >+ <tt>table</tt>, <tt>Table</tt> and <tt>TABLE</tt> are all the same. Nit: This line looked better when it was a list item. >+<h2><a name="features">Features</a></h2> >+ >+<ul> ... >+</ul> Nit: I wouldn't mind if there would still be empty line between list items here. Maybe add some CSS? >+<p> >+ Use the powerful <a href="query.cgi">[% terms.Bugzilla %] Query Form</a> >+ for advanced queries. >+</p> Nit: Query Form has been renamed. >--- head/template/en/default/pages/quicksearchhack.html.tmpl 1970-01-01 01:00:00.000000000 +0100 >+++ patched/template/en/default/pages/quicksearchhack.html.tmpl 2005-07-07 20:47:17.863742400 +0200 >+ # The Original Code is the Bugzilla Bug Tracking System. >+ # >+ # Contributor(s): N.N. Netscape reference missing from here too. >+ onsubmit="if (this.quicksearch.value == '') >+ { alert('Please enter some search criteria first.'); >+ return false; } return true;"> Same wording change here as above. >+ <input type="submit" name="run" value="Search"> Same change as above. >+ For example, <tt>owner,reporter,qa:ibm,sun</tt> will give you >+ [%+ terms.bugs %] where the owner, reporter, or qa contact has a login Bug 76507 changed the term owner to assignee. Note the two other changes too. >+<thead> >+<tr> >+ <th>Searched by default</th> >+ <th>Shortcut</th> >+ <th>Field Name</th> >+ <th>Aliases</th> >+ <th>Description</th> >+</tr> >+</thead> Nit: These were better left justified than centered. Maybe add some CSS? >+<thead> >+<tr> >+ <th>Syntax</th> >+ <th>Semantics and Examples</th> >+</tr> >+</thead> Ditto.
Attachment #189237 - Flags: review? → review-
Attached patch Patch 2.1 (obsolete) — — Splinter Review
Thank you for your review! Here is an updated patch. > 1) Runtests fail, on test 1: > > not ok 86 - Bugzilla/Search/Quicksearch.pm --ERROR > # Failed test (t/001compile.t at line 95) > Can't locate Bugzilla.pm in @INC (@INC contains: > /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 > /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi > /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl > /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl > /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0) at > Bugzilla/Search/Quicksearch.pm line 25. > BEGIN failed--compilation aborted at Bugzilla/Search/Quicksearch.pm line 25. Strange, I cannot reproduce this. Test 1 passes for me. > and on test 2: > > not ok 86 - Bugzilla/Search/Quicksearch.pm is a module, but has a shebang > # Failed test (t/002goodperl.t at line 59) Fixed. Sorry. > 2) Patch doesn't remove localconfig.js, which seems to be unneeded now. Removed. > 3) There's still wrong quicksearch help link in using.xml aroung line 730. > Maybe add a note there that QuickSearch can also be found in the footer too? Done. > 4) What is localconfig.rdf file? I can't find anything that creates or uses it. > Bugxula seems to use it for something so I wonder if it really is related to > QuickSearch after all. If this is the case, references to it shouldn't be > removed.. Well, I don't remove references. I just don't add a positive access rule to .htaccess any more. > 5) Nit: config.js.tmpl template seems to still refer to quicksearch.js in a > comment around line 22. Corrected. > Reference to Netscape is missing here. No; we're not adding these to new files unless they need to inherit it from older code (see https://bugzilla.mozilla.org/show_bug.cgi?id=119485&mark=15#c15). The old code didn't contain any references to Netscape, so there is no need to put them here. In fact, we should avoid putting them here. Same goes for other places you found. > >+# Contributor(s): Marc Schumann <wurblzap@gmail.com> > >+# Andreas Franke <afranke@mathweb.org> > >+# Stephen Lee <slee@uk.bnsmc.com> > >+# C. Begle > >+# Jesse Ruderman > > Nit: These seem to be normally listed from earlier to recent so I would > switch them around. I put myself on top because it's a complete port in a new file... Ok, reordered. > >+# Make it harder for us to do dangerous things in Perl. > >+use strict; > > Should there be a package directive too? Yes. Added one. > >+use base qw(Exporter); > >+@Bugzilla::User::EXPORT = qw(quicksearch); > > Err.. Bugzilla::User? Shouldn't that be Bugzilla::Search::QuickSearch? Yes, it should. Sorry for the oversight. > >+# Word renamings > >+my %mappings = ("status" => "bug_status", > > Nit: The first comment is missing. The one that should say "# Status, > Resolution, Platform, OS, Priority, Severity". It seems to have gotten lost during the transfer. Added it again. > And yes, please, get these incorporated into fielddefs or something to that > effect. A follow up bug is fine with me, though. :) Yes. That's been a part of QuickSearch all the time, so let's please fix it somewhere else :) > >+# We might want to put this into localconfig or somewhere > >+my @platforms = ('pc', 'sun', 'macintosh', 'mac'); > > Erm.. Couldn't these come from the DB instead of this ugly hardcoding? Sure, but not from what we have right now. We'd need an individual table for just this, and if we really want to do this, then please in a separate bug :) This is a list of shortcuts which should trigger searches on platform -- we cannot use the rep_platform table for this. > Shouldn't bugidtype be set too? Ok, did that. It's not necessary because it defaults to "order" if not set, but I agree it's cleaner to set it. > Looks like following translation is missing: > // translate " AND "," OR "," NOT " to space,comma,dash > This makes the those words to be treated like search terms.. :( Seems to have gotten lost. Good catch. Added them. > >+ # Priority > >+ elsif ($word =~ m/^[pP]([1-5]-[1-5])$/) { > >+ addChart('priority', 'regexp', > >+ "[$1]", $negate); > >+ } > > Where's the other priority matching? Now search terms like p1 doesn't work. > :( Try it -- it works ;) This adds a boolen chart "priority"-"matches regexp"-"[x-y]", which means if you enter p1-3 you'll get bugs with priorities matching /[1-3]/, which is exactly what we want. > >+# We are therefore interested in query fields only, which means we ignore > >+# non-query fields like order and cmdtype. > > Nit: Why like? We only ignore those two fields.. s/non-query fields like order and cmdtype/non-query fields/ > >-<FilesMatch ^(localconfig.js|localconfig.rdf)$> > >- allow from all > >-</FilesMatch> > > Nit: This leaves localconfig.js allowance into .htaccess but maybe that's not > that big of a deal. There seems to be runtest.sh deny left in there too.. That's what I think, too. > For readability, name this quicksearch_max_terms. Maybe the first description > line would be more accurate as "The maximum number of search terms allowed in > a QuickSearch." ? Done. > Hmm.. Would this error be better as "Please enter one or more search terms > first."? Ok. Done in all places you mentioned. > >+ [% title = "Too many search terms" %] > >+ The database can only cope with so many QuickSearch terms. > >+ In order to go easy on it, the number of search terms is limited > >+ to [% Param('quicksearchmaxterms') %]. > > Nit: Hmm.. would this be better if it states the original reason for the > limitation too? It was limited because otherwise the query would take > forever.. Reworded. > >+ <input type="text" size="40" name="quicksearch"> > >+ <input type="submit" name="run" value="Search"> > > Remove name="run" from the button so it won't appear in the generated URL. > Also name the button as Find. Done and done. Other places, too. > Nit: These subtitles look funny because they are now bigger than the main > title.. Same goes for the quicksearchhack.html.tmpl template. While I tend to agree, I'd rather leave it the way it is for now. > >+ <tt>table</tt>, <tt>Table</tt> and <tt>TABLE</tt> are all the same. > > Nit: This line looked better when it was a list item. Back to list item. > >+<h2><a name="features">Features</a></h2> > >+ > >+<ul> > ... > >+</ul> > > Nit: I wouldn't mind if there would still be empty line between list items > here. Maybe add some CSS? Did that. Looks better now to my eyes. > Nit: Query Form has been renamed. Fixed. Other places, too. > >+ For example, <tt>owner,reporter,qa:ibm,sun</tt> will give you > >+ [%+ terms.bugs %] where the owner, reporter, or qa contact has a login > > Bug 76507 changed the term owner to assignee. Note the two other changes too. Fixed. > Nit: These were better left justified than centered. Maybe add some CSS? I like them better centered, but I squashed them to the left now so that it looks like the original.
Attachment #189237 - Attachment is obsolete: true
Attachment #190825 - Flags: review?(wicked)
Comment on attachment 190825 [details] [diff] [review] Patch 2.1 >+++ patched/Bugzilla/Search/Quicksearch.pm 2005-07-28 13:21:51.270142200 +0200 >+# We might want to put this into localconfig or somewhere >+my @platforms = ('pc', 'sun', 'macintosh', 'mac'); Why not using @::legal_platform ?? None of these platforms matches with my customised ones. >+ # Platform >+ if (grep({lc($word) eq $_} @platforms)) { >+ addChart('rep_platform', 'substring', >+ $word, $negate); >+ } @::legal_platform >+ # Priority >+ elsif ($word =~ m/^[pP]([1-5]-[1-5])$/) { >+ addChart('priority', 'regexp', >+ "[$1]", $negate); >+ } @::legal_priority (/me has changed them a long time ago to "Top Priority", "High Priority", "Low Priority", ....) Now that almost everything is customisable in Bugzilla, it doesn't make sense to hardcode such things. I don't officially r- this patch because I didn't read the too many comments in the bug, so I have no idea what has already been discussed. But I could if you don't give me a good reason not to use @::global_variables.
(In reply to comment #148) > >+# We might want to put this into localconfig or somewhere > >+my @platforms = ('pc', 'sun', 'macintosh', 'mac'); > > Why not using @::legal_platform ?? None of these platforms matches with my > customised ones. Because we simply *don't want* to be this list to be equal to the list of legal platforms. This list is meant to be a very much shortened list of abbreviations. > >+ # Priority > >+ elsif ($word =~ m/^[pP]([1-5]-[1-5])$/) { > >+ addChart('priority', 'regexp', > >+ "[$1]", $negate); > >+ } > > @::legal_priority (/me has changed them a long time ago to "Top Priority", > "High Priority", "Low Priority", ....) Doesn't work here -- this takes care of *ranges* (P1-3 and so on). If you customized your priority values away from the default, you can't use this feature. But it isn't in your way, either. > Now that almost everything is customisable in Bugzilla, it doesn't make sense > to hardcode such things. I don't officially r- this patch because I didn't read > the too many comments in the bug, so I have no idea what has already been > discussed. But I could if you don't give me a good reason not to use > @::global_variables. Don't r- because of things out of scope. This bug is about porting QuickSearch, and if QuickSearch has shortcomings (I agree it has), then let's fix them in separate bugs.
Blocks: 302510
Blocks: 302511
(In reply to comment #147) > > 4) What is localconfig.rdf file? I can't find anything that creates or uses ... > Well, I don't remove references. I just don't add a positive access rule to > .htaccess any more. Yeah, and that could break things when new installation doen't have this allowed anymore. Myk says on bug 72837 comment 35: "localconfig.rdf has never been in a released version of Bugzilla, so changes to it are an installation-specific (f.e. b.m.o) problem." so I guess this change is OK. Anyhow Bugxula and other third parties have manual instructions on how to generate this file so I'm sure they can amend them to allow retrieval of localconfig.rdf where needed. Besides, this code doesn't remove existing allow clause from .htaccess file. :) > > Reference to Netscape is missing here. > > No; we're not adding these to new files unless they need to inherit it from > older code (see > https://bugzilla.mozilla.org/show_bug.cgi?id=119485&mark=15#c15). The old code > didn't contain any references to Netscape, so there is no need to put them > here. In fact, we should avoid putting them here. Ah, OK. Works for me. Approver can yell if they disagree. :) > > >+# We might want to put this into localconfig or somewhere > > >+my @platforms = ('pc', 'sun', 'macintosh', 'mac'); ... > This is a list of shortcuts which should trigger searches on platform -- we > cannot use the rep_platform table for this. Ah, I see. I think it might still be good to combine these with actual platform values. But let's leave that for another bug, I don't really want to change the QuickSearch API with this rewrite. :) > > >+ # Priority > > >+ elsif ($word =~ m/^[pP]([1-5]-[1-5])$/) { > > Where's the other priority matching? Now search terms like p1 doesn't work. > Try it -- it works ;) I did, it doesn't. > This adds a boolen chart "priority"-"matches regexp"-"[x-y]", which means if > you enter p1-3 you'll get bugs with priorities matching /[1-3]/, which is > exactly what we want. Yes, p1-3 works but p1 doesn't. Old JavaScript code had two blocks for handling priority. In addition to the one in perl code there is this: // priority if (w.match("^[pP][1-5](,[pP]?[1-5])*$")) { expr = "["+w.replace(/[p,]/g,"")+"]"; add_chart("priority","regexp",expr); continue; } If I'm not mistaken, that handles terms in the form "p1", "P4" and "p2,p5". (Next I'll quickly review the updated patch.)
Comment on attachment 190825 [details] [diff] [review] Patch 2.1 Runtests pass now and brief tests seem to generate correct search. I think this is really close now. >+# Make it harder for us to do dangerous things in Perl. >+use strict; >+ >+package Bugzilla::Search::Quicksearch; Nit: I think package should be first thing on a module. >+ # People: AssignedTo, Reporter, QA Contact, CC, Added comment (?) >+ "assignee" => "assigned_to", >+ "assignedto" => "assigned_to", I don't think we should remove owner from this mapping table. That would break API. It doesn't need to appear on help page, I would consider it a deprecated feature. :) >+ ThrowUserError('buglist_parameters_required') unless ($searchstring); If this happens, QuickSearch crashes with Undefined subroutine &Bugzilla::Search::Quicksearch::ThrowUserError error. Same thing probably affects other Throw*Error calls.
Attachment #190825 - Flags: review?(wicked) → review-
Attached patch Patch 2.2 (obsolete) — — Splinter Review
Thanks again for the quick turnaround :) > Ah, I see. I think it might still be good to combine these with actual > platform values. But let's leave that for another bug, I don't really want to > change the QuickSearch API with this rewrite. :) See bug 302510. > > Try it -- it works ;) > I did, it doesn't. You're right. I've merged the missing section into the one caring about priority ranges now. In quicksearch.js as well as Quicksearch.pm, comma separation is done several lines above this part of the code, so I dropped the (thus obsolete) bit here. See bug 302511 for this being specific to the default priority values. > Nit: I think package should be first thing on a module. Moved it up so that it agrees with Bug.pm. I had taken the placement from Search.pm -- it turns out we're really not very consistent in this regard. > I don't think we should remove owner from this mapping table. That would break > API. It doesn't need to appear on help page, I would consider it a deprecated > feature. :) Added again, and marked as such. > >+ ThrowUserError('buglist_parameters_required') unless ($searchstring); > > If this happens, QuickSearch crashes with Undefined subroutine > &Bugzilla::Search::Quicksearch::ThrowUserError error. Same thing probably > affects other Throw*Error calls. A well-placed use Bugzilla::Error can work wonders.
Attachment #190825 - Attachment is obsolete: true
Attachment #190894 - Flags: review?(wicked)
Comment on attachment 190894 [details] [diff] [review] Patch 2.2 Hmm.. Looks like JavaScript didn't actually limit the words to 4 as it's Search function is always called with searchLong parameter set to false. This also means comments are not searched. Atleast not without local customization. Is this intentional change? Actual reason for the r- is that Rob was right. Editing saved searches is busted with this patch. :( Try running any saved search (even one saved from other than a QuickSearch) and then clicking Edit Search. You should find that the form is empty. However, Edit Search does work for any normal search, including QuickSearch.
Attachment #190894 - Flags: review?(wicked) → review-
Instead of creating a completely different search interface in a new Quicksearch.pm module, we should be enhancing the current search interface in the existing Search.pm module with the necessary features to support quicksearch functionality. Not only would that mean less code to maintain, it provides quicksearch functionality to the existing Advanced Search and Find a Specific Bug interfaces while simultaneously providing Search.pm functionality (particularly fulltext searching) available to quicksearch interfaces.
Attached patch Patch 2.3 (obsolete) — — Splinter Review
(In reply to comment #153) > Hmm.. Looks like JavaScript didn't actually limit the words to 4 as it's > Search function is always called with searchLong parameter set to false. This > also means comments are not searched. Atleast not without local customization. > Is this intentional change? This was not intentional. I seem to have misread the original code. I changed it so that I'm not limiting the number of terms any more, but cutting off searching comments if there are too many search terms. > Actual reason for the r- is that Rob was right. Editing saved searches is > busted with this patch. :( Fixed by removal -- the modification in question seems to have been made obsolete by another patch in the meantime anyway. (In reply to comment #154) By its very design, QuickSearch is a wrapper around Search.pm. With the patch, QuickSearch functionality is immediately available to Specific and Advanced Search, and QuickSearch can be easily enhanced to make use of newer Search.pm features like fulltext search.
Attachment #190894 - Attachment is obsolete: true
Attachment #191349 - Flags: review?(wicked)
Comment on attachment 191349 [details] [diff] [review] Patch 2.3 Sorry, still found some errors.. 1) The Load Search Form loads the Find Specific Bug tab if that was last used. Shouldn't this always go to the Advanced Search tab? 2) With this patch, following errors are been emitted to error log: query.cgi: Character in "c" format wrapped at Bugzilla/Util.pm line 137. Can be atleast triggered by simply going to query.cgi without any parameters. 3) Nit: Shouldn't quicksearch parameter removed from the generated links so it won't get passed around unnecessarily?
Attachment #191349 - Flags: review?(wicked) → review-
Attached patch Patch 2.4 — — Splinter Review
(In reply to comment #156) > 1) The Load Search Form loads the Find Specific Bug tab if that was last used. > Shouldn't this always go to the Advanced Search tab? Makes sense to me. Added format=advanced. > 2) With this patch, following errors are been emitted to error log: > query.cgi: Character in "c" format wrapped at Bugzilla/Util.pm line 137. > Can be atleast triggered by simply going to query.cgi without any parameters. I can't reproduce this (maybe because of the next fix). > 3) Nit: Shouldn't quicksearch parameter removed from the generated links so it > won't get passed around unnecessarily? QuickSearch now strips its specific CGI parameters, and its results are now correctly accepted by buglist.cgi into its $buffer.
Attachment #191349 - Attachment is obsolete: true
Attachment #192270 - Flags: review?(wicked)
No longer blocks: 221481
*** Bug 221481 has been marked as a duplicate of this bug. ***
Note attachment 192562 [details] [diff] [review] in bug 234464. It is, I think, a preferable approach to server-side quicksearch, not only because the syntax is far more intuitive than quicksearch's (and thus much easier to learn and retain) but also because the integration with the existing "find a specific bug" (and any other "content search" field in Bugzilla) is simpler. Of course, it's also not as powerful as quicksearch, but useful quicksearch features could be integrated into it as long as they didn't compromise its intuitiveness. I suggest we implement an approach like the one in that attachment rather than moving quicksearch to the server.
(In reply to comment #159) I really don't think the two bugs conflict... I fact, I think it makes sense to have QuickSearch available on the server... For bug 234464, for example ;) If nothing else, we should get rid of localconfig.js cruft :)
Comment on attachment 192270 [details] [diff] [review] Patch 2.4 FWIW, this looks good to go. Randomly tested different QuickSearch features including saving them. I didn't look at what myk created but this patch considerably cleans up and enhances old JS based code. I personally like this more powerfull find in the footer. Not to mention this would finally close this monster of a bug. :) If this ends up been rejected then somebody needs to kill QuickSearch. Four different and overlapping search features would be way too much, IMO.
Attachment #192270 - Flags: review?(wicked) → review+
Flags: approval?
Flags: approval? → approval+
One thing that concerns me about the patch on this bug is that it seems to remove access to localconfig.rdf. Granted, clients may be using config.cgi instead, but are you sure that's always the case? localconfig.rdf isn't related to quicksearch (it's for third-party clients like Bugxula). Is there a reason you are removing it in the context of this quicksearch rearchitecture?
Checking in QUICKSTART; /cvsroot/mozilla/webtools/bugzilla/QUICKSTART,v <-- QUICKSTART new revision: 1.5; previous revision: 1.4 done Checking in buglist.cgi; /cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v <-- buglist.cgi new revision: 1.306; previous revision: 1.305 done Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.430; previous revision: 1.429 done Checking in defparams.pl; /cvsroot/mozilla/webtools/bugzilla/defparams.pl,v <-- defparams.pl new revision: 1.165; previous revision: 1.164 done Removing localconfig.js; /cvsroot/mozilla/webtools/bugzilla/localconfig.js,v <-- localconfig.js new revision: delete; previous revision: 1.2 done Removing quicksearch.html; /cvsroot/mozilla/webtools/bugzilla/quicksearch.html,v <-- quicksearch.html new revision: delete; previous revision: 1.3 done Removing quicksearch.js; /cvsroot/mozilla/webtools/bugzilla/quicksearch.js,v <-- quicksearch.js new revision: delete; previous revision: 1.12 done Removing quicksearchhack.html; /cvsroot/mozilla/webtools/bugzilla/quicksearchhack.html,v <-- quicksearchhack.html new revision: delete; previous revision: 1.6 done RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search/Quicksearch.pm,v done Checking in Bugzilla/Search/Quicksearch.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search/Quicksearch.pm,v <-- Quicksearch.pm initial revision: 1.1 done Checking in docs/xml/security.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/security.xml,v <-- security.xml new revision: 1.7; previous revision: 1.6 done Checking in docs/xml/using.xml; /cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v <-- using.xml new revision: 1.35; previous revision: 1.34 done Checking in skins/standard/global.css; /cvsroot/mozilla/webtools/bugzilla/skins/standard/global.css,v <-- global.css new revision: 1.15; previous revision: 1.14 done Checking in template/en/default/config.js.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/config.js.tmpl,v <-- config.js.tmpl new revision: 1.5; previous revision: 1.4 done Checking in template/en/default/index.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/index.html.tmpl,v <-- index.html.tmpl new revision: 1.24; previous revision: 1.23 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.18; previous revision: 1.17 done Checking in template/en/default/global/useful-links.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/useful-links.html.tmpl,v <-- useful-links.html.tmpl new revision: 1.40; previous revision: 1.39 done RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/quicksearch.html.tmpl,v done Checking in template/en/default/pages/quicksearch.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/quicksearch.html.tmpl,v <-- quicksearch.html.tmpl initial revision: 1.1 done RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/quicksearchhack.html.tmpl,v done Checking in template/en/default/pages/quicksearchhack.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/quicksearchhack.html.tmpl,v <-- quicksearchhack.html.tmpl initial revision: 1.1 done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Blocks: 236025
Blocks: 101515
Keywords: relnote
Added to the Bugzilla 2.22 Release Notes in bug 322960.
Keywords: relnote
Whiteboard: #*#*#*# PLEASE READ COMMENT #131 BEFORE POSTING COMMENTS #*#*#*# → #*#* THIS BUG IS FIXED IN BUGZILLA 2.22. DO NOT COMMENT. #*#*
Depends on: 364056
Depends on: 366120, 366121
I DO NOT KNOW WHAT IS BEING SAID IN HERE, SORRY. I JUST WANT THIS BUG OUT OF MY SYSTEM SO I CAN CHAT LIKE BEFORE I UPDATED WITH IMVU.
Your caps lock key seems to be stuck, Dina.
Blocks: 400243
i receive the following. { The 'bug number' is invalid. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907. } When trying to add a new bug. i was able to do so just fine and have changed absolutely nothing.
i receive the following. { The 'bug number' is invalid. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907. } When trying to add a new bug. i was able to do so just fine and have changed absolutely nothing. I am not using quicksearch. Any help.
Blocks: 490562
No longer blocks: 72947
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: