I've just tried to change a Product in an existing bugreport but Component list was not updated by that change and was still showing component list for "old" Product. To reproduce: 1. Open some bugreport at bugzilla.mozilla.org 2. Try to select different Product 3. Observe that Component list was not updated according to the chosen Product

works as designed. you have to click submit and it'll prompt you to set the new component. The overhead involved in supplying every possible component of every product is too big to be worth giving that list to the show_bug page.

Ok. But why then not make list empty on Product change? Or turn it into a single option like "Specify later..."? Current behavior is very confusing. btw, WONTFIX seems to be more suitable resolution to your comment than WORKSFORME. Reopenning for further comments / final resolution.

Hmmm... "Specify Later..." I'll go for that. :) Would be nice and easy to do, too.

a) The overhead involved in supplying the components is similar to the overhead in query.cgi -- namely, complicated javascript. :-) b) I'm unclear as to what is being proposed here. Do you mean having a blank components list in show_bug? Or when product is changed, blank out the component list?

preferably replace the component list (and probably version and milestone) with "Select later" or something like that. To be safe, we probably want to stash the original list, and replace it (and its selection) if they change the product back to the original one before submitting.

>The overhead involved in supplying the components is similar to the overhead >in query.cgi -- namely, complicated javascript. :-) Right. Which isn't that much overhead at all, especially if we reuse the code. I think updating the components list like we do on the query form is the right approach, since then users don't have to load, parse, and act upon an additional page when making this change.

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

(In reply to comment #6) > >The overhead involved in supplying the components is similar to the overhead > >in query.cgi -- namely, complicated javascript. :-) > > Right. Which isn't that much overhead at all, especially if we reuse the code. Unless you have products with 3000 components in them. (Thinking of the RedHat and Ubuntu bugzillas)

Just for the record, when I was in charge of the Ubuntu Bugzilla, I used to get a couple complaints a week from people on dialup about how long it took to load show_bug.cgi for a bug in the Ubuntu product (because of having to load that 3000 item component list for the component dropdown). We ended up moving the component list into a separate js file so it could be cached and then having the javascript populate it after the page loaded, but the caching appeared to break when it moved to https.

At Red Hat they have a "Use javascript" link that you can use to *turn on* JS on the page. So by default the JS components stuff is off, which helps the dial-up users.

That's definitely something I would like to see implemented in 2.24. We unfreeze in two weeks. ;)

This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This is a frequent workflow breaker which is very confusing, even if you already know about it. In the age of AJAX and DSL, the technical limitations mentioned in some comments have become irrelevant. I agree with Frédéric's comment 11 from 2006 that this would be a very desirable improvement.

This can easily be accomplished by using the value-controller JS, particularly once bug 636416 goes in.

However, we should still be vary careful about performance issues when you have a lot of products or components. Having a slow query.cgi is bad, but having a slow show_bug.cgi is totally unacceptable.

IMO, it would be better to use WS (or the same code as user auto-completion) to get the new component list, instead of making the page even bigger by loading everything into a JS script.

... and if JS is disabled or it's not possible to get the data, then display the intermediate page as we do now.

Doing things via the WS may be the way to go. My suspicion is that it will be ideal for large lists and not a good idea for small lists, so we will want to use a hybrid solution. I think we can adjust the value-controller JS to do this, but I also think that we should do some testing to see at what point this actually gets slow before we make any decisions. (Keeping code simplicity in mind, of course, as well.)

I did something similar to this at Red Hat except it was not taking into account value controls, etc. Basically when the component count was > 50, we did the ajax call to get the whole list if the user clicked on (edit) next to the component name similar to editing assignee, etc. I added a component_count() sub to Product.pm so that it could quickly get a count of components using SQL instead of counting the length of product.components (very big). Reason for this was Fedora for example has 6000+ components. That being said, Red Hat would definitely not go for having all components for all products in JS for show_bug.cgi. dkl

Note: This is *already implemented* for the Advanced Search page, see http://bzr.mozilla.org/bugzilla/trunk/annotate/head:/js/productform.js "Reads the selected products and updates component, version and milestone lists accordingly."

(In reply to Waldir from comment #27) > Note: This is *already implemented* for the Advanced Search page, see > > "Reads the selected products and updates component, version and milestone > lists accordingly." The problem with this code though is the list of components, version and milestones is loading in the HTML. While taking this approach works on smaller sites, larger sites (like brc, where we have 63,000+ components) would blow the page load time and the page rendering time. Therefore the approach I am going to take is to use AJAX. For sites that don't have JSON-RPC, they will see what they see now.

It's a bzr bundle since it contains a new gif file. If you prefer a patch + image, let me know. Known caveat with this change: If the current product only has one version or one milestone, then no select box will show up for that value (no JS error either). The best solution for this is to always show the select box. Let me know if you want this to happen. The field-ajax.js file has some code relating to the 'anyval' variable. This will be used as part of bug 921566 and bug 921353. I will submit new patches for those bugs once this code has hit trunk.

Why is the code so different from what has been done in bug 22353? Wouldn't it make sense to share some code between both features? At least the way to call our WebServices and to return data. Note that I'm not a JS expert at all, so this is just a suggestion/question.

> Attachment #8348374 [details] [diff] - Attachment is patch: true I didn't know if a bzr bundle was considered a patch or not. (In reply to Frédéric Buclin from comment #31) > Why is the code so different from what has been done in bug 22353? Looking at js/bug.js, I don't think is is anything that could be shared here. bug.js populates a YUI2 DataTable complete with formatting, while this code updates one or more drop down box. You couldn't even share the code to call our WebServices, since the init in js/bug.js makes reference to the DataTable object. Or at least I don't think it is possible from the little bit of YUI2 that I know. Am happy for a YUI2 knowledgeable person to tell me otherwise. -- simon

(In reply to Simon Green (away until Jan 20th) from comment #30) > The best solution for this is to always show the select box. > Let me know if you want this to happen. Select boxes should always be visible, yes. (In reply to Myk Melez [:myk] [@mykmelez] from comment #6) > approach, since then users don't have to load, parse, and act upon an > additional page when making this change. There will always be the intermediate page as long as groups are involved. Said differently, loading components dynamically (and the code associated with it) is of no use if the intermediate page will be displayed due to new groups being available or old groups becoming unavailable. So either we fix this problem, or the new AJAX code is useless.

(In reply to Frédéric Buclin from comment #33) > (In reply to Simon Green (away until Jan 20th) from comment #30) > > The best solution for this is to always show the select box. > > Let me know if you want this to happen. > > Select boxes should always be visible, yes. Okay, I'll fix this after the review is done. > (In reply to Myk Melez [:myk] [@mykmelez] from comment #6) > There will always be the intermediate page as long as groups are involved. > Said differently, loading components dynamically (and the code associated > with it) is of no use if the intermediate page will be displayed due to new > groups being available or old groups becoming unavailable. So either we fix > this problem, or the new AJAX code is useless. I disagree. Being able to select the new component, version and milestone is of help, but having the groups on a separate page is mandatory. If you move a bug to a product that has no groups (or not the same groups as original product) you want a nice warning about that. You would also need to do the same with flags (since flags can differ between products). As I see it, this patch is a good start. Doing the groups and flags would require changes to RPC as well (since Product.get doesn't give us group information currently), and that should a separate bug. YMMV. -- simon

(In reply to Simon Green (away until Jan 20th) from comment #34) > I disagree. Being able to select the new component, version and milestone is > of help If of help for what? To get the intermediate page anyway? It would only be helpful if the component, version and milestone are not editable again in the intermediate page. > but having the groups on a separate page is mandatory. If you move > a bug to a product that has no groups (or not the same groups as original > product) you want a nice warning about that. I totally agree, which is why I think AJAX doesn't help your workflow as you get that page anyway.

No action on this bug in a while, and it's not necessary for 5.0.

Most new triagers don't know the right product anyway. The search box at https://bugzilla.mozilla.org/enter_bug.cgi?full=1 gets around that by letting you search on the component names and descriptions. Triagers should be able to use this from the bug editing screen to pick a component by searching.

Does this bug also cover the “show info” link? It only shows the description for the current product and component, instead of the newly selected ones.

(In reply to Gingerbread Man from comment #40) > Does this bug also cover the “show info” link? It only shows the description > for the current product and component, instead of the newly selected ones. Pretty sure that could be fixed separately.

(In reply to :Gijs Kruitbosch from comment #41) > Pretty sure that could be fixed separately. The good news is a report for the Show Info link already exists (it wasn't easy to find). The bad news is someone proposed essentially wontfixing it. Bug 1081833