227611 - Components list should dynamically update when changing the product on the "show_bug.cgi" page

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, enhancement, P1)

Description

[Max Alekseyev]

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

Comment 1

[Dave Miller [:justdave]]

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.

Comment 2

[Max Alekseyev]

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.

Comment 3

[Dave Miller [:justdave]]

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

Comment 4

[Christian Reis]

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? 

Comment 5

[Dave Miller [:justdave]]

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.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

>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.

Comment 7

[WADA:World Anti-bad-Duping Agency]

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

Comment 8

[Dave Miller [:justdave]]

(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)

Comment 9

[Dave Miller [:justdave]]

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.

Comment 10

[Max Kanat-Alexander]

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.

Comment 11

[Frédéric Buclin]

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

Comment 12

[Frédéric Buclin]

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".

Comment 14

[Max Kanat-Alexander]

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.

Comment 16

[Thomas D. (:thomas8)]

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.

Comment 20

[Max Kanat-Alexander]

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

Comment 21

[Max Kanat-Alexander]

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.

Comment 22

[Frédéric Buclin]

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.

Comment 23

[Frédéric Buclin]

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

Comment 24

[Max Kanat-Alexander]

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.)

Comment 25

[David Lawrence [:dkl]]

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

Comment 27

[Waldir Pimenta]

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."

Comment 29

[Simon Green]

(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.

Comment 30

[Simon Green]

Attachment: v1 bundle

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.

Comment 31

[Frédéric Buclin]

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.

Comment 32

[Simon Green]

> 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

Comment 33

[Frédéric Buclin]

(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.

Comment 34

[Simon Green]

(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

Comment 35

[Frédéric Buclin]

(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.

Comment 36

[Mark Côté [:mcote]]

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

Comment 39

[Benjamin Smedberg]

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.

Comment 40

[Gingerbread Man]

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.

Comment 41

[:Gijs (he/him)]

(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.

Comment 42

[Gingerbread Man]

(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

Comment 43

[Kohei Yoshino [:kohei]]

This has already been solved in the default modal UI, which will be shipped with Bugzilla 6.