Loads of javascript warnings in quicksearch.js

RESOLVED FIXED in Bugzilla 2.14



18 years ago
6 years ago


(Reporter: gerv, Assigned: afranke)


Bugzilla 2.14



(1 attachment)

If you turn on strict JS checking in Mozilla using
(user_pref("javascript.options.strict", true);
then quicksearch.js produces a whole lot of warnings.


Comment 1

18 years ago
Created attachment 27346 [details] [diff] [review]
patch to fix JS strict warnings in quicksearch.js (diff -u)

Comment 2

18 years ago
So, maybe someone can glance over it and check it in? Gerv has already had a
	<Gerv> I can't see anything wrong with it.
Keywords: approval, patch

Comment 3

18 years ago
Since there is a patch, I'm setting the target milestone to get it on the radar.
Feel free to push it out as appropriate.
Target Milestone: --- → Bugzilla 2.12
It *looks* pretty straightforward, but based on past experience with cleaning up 
JavaScript errors elsewhere in Bugzilla, and the various different ways that 
different browsers handle JavaScript errors anyway, this will take too much 
testing to verify that it's safe.

Am I correct that it's not actually broken, right now, you just get warnings?  
(i.e. nothing that stops it from running, right?)  If so, I think this can wait 
for 2.16 when we have more time to test.
Target Milestone: Bugzilla 2.12 → Bugzilla 2.16

Comment 5

18 years ago
Yes, you are correct. AFICT nothing is broken right now.
attachment 35006 [details] [diff] [review] on bug 77699 has been checked in, and included the fix for this 
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 7

18 years ago
Thanks, Dave. Now my local quicksearch.js is in sync with the cvs tip again.
I played around with mozilla with "javascript.options.strict" set to true,
and on the JavaScript console, most of the time there aren't any warnings any
more (on my bugzilla installation, that is; bugzilla.mozilla.org doesn't seem to
have upgraded yet).

I found one case where there is still a javascript warning: if the quicksearch
input has leading or trailing whitespace. This is more than a cosmetic problem
since in this case, the generated query url is indeed different from the one
that is generated from the same input with leading and trailing whitespace
stripped. However, it has no consequences because the generated additional
constraints are always satisfied: the additional constraint is that the empty
string is a substring of either the status whiteboard or the summary.


Since the empty string is a substring of any string, this doesn't make a
difference wrt. the resulting bug list. I don't think we need to open an
additional bug for that. I'll make sure that a fix for it is included in the
next patch to the quicksearch.js file. I'll attach it here for reference then.

If anyone finds more warnings (or real bugs), please report them, here or in new
in search of accurate queries...  (this was fixed in 2.14)
Target Milestone: Bugzilla 2.16 → Bugzilla 2.14
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: Bugzilla 2.11 → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.