If a product has no component, query.cgi associates wrong components with products. That's a regression due to bug 312876 where the JS code lists *all* selectable products while the dropdown menu only lists selectable products having at least one component. As the JS code uses the index of the item in the product list instead of the name of the product itself, all associations are shifted by at least one.
The best fix I can imagine for this bug is to backout bug 312876. If we fix it when useclassification is turned off, I'm almost sure it will break when we turn it on again (because some counters are incremented even when the product has no component, so we have missing indexes). ;)
This isn't a blocker, because products with no components is a really dumb thing to do (and easy to work around). But yes, at this stage perhaps the best solution is to back out that patch.
Created attachment 255773 [details] [diff] [review] Simple fix to JS Array contents, V1 Here's a patch that fixes JS Arrays to contain only components, versions and milestones for products that have components. These are the only products that are selectable because the product select box only contain such products. I tested this with and without classifications and it seems to do the trick. With classifications turned on the JS code used stored indexes for product based data so the counting problem did not occur.
Comment on attachment 255773 [details] [diff] [review] Simple fix to JS Array contents, V1 works fine. r=LpSolit
Checking in template/en/default/search/form.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/form.html.tmpl,v <-- form.html.tmpl new revision: 1.47; previous revision: 1.46 done