I'm filing this in general because it really entails 3 components. Admin, Query, and UI. To fix this bug we need to have the JS file be updated automatically. I think it would be best to update it whenever a new product, component, version, or milestone are added/removed. It also might be good to implement an optional timed update. This has significant advantages. 1) The current JS uses multiple dashes --- in it's code. Since some older browsers don't support the <script> tag, we surround the JS in HTML comments <!-- -->. However, it is illegal in SGML to have multiple dashes within comments. This therefore affects our ability to have HTML/XHTML compliant code. 2) The perl code would not have to fetch and print all the available components @ runtime saving some time. 3) The JS would be more readily accessed by others for modification if desired. 4) View source on the query page would look better also.

Target same as 47251.

The functionality of getting the arrays moved over is 72837. Adding dep. This bug will to move the rest of the code over to a separate JS file. This isn't dependent per say on 96534, but if we are redoing the JS, it should wait until that is done also so adding dependency there too.

Note JS bug http://bugzilla.mozilla.org/show_bug.cgi?id=81935 - could it spell trouble for us if a fix lands?

The JS has to be dynamically generated. If you make it static it introduces a huge security hole for sites that have hidden products. If the user is not logged in or does not have access to a product group, that product is not to be displayed to the user on the query screen. Not even if they view source on it. Explain to me how to overcome that in a static file and you can feel free to reopen this.

There _could_ be a static page collection from which the appropriate pages got loaded per-permission. I can't see an easy way to implement this, but Christopher always has good ideas. :)

It can be a *.pl file that outputs text/javascript. Updating summary and REOPENING

Remember, the runtime fetching issue could be an important one for people with very large bugzilla installs, since the page size for public products is around 300k without my bug 96534 patch, and 150k with it. Changing the js to a perl file won't fix this. Perhaps a public_products_load_static=1 option/parameter could be introduced?

I doubt that's a good idea. The only solution would be to generate a different JS file for each user groupset. Because they would only be generated on first use, every combination of groupset would not be realised in practice. If this would be too many combinations for an installation, we could certainly turn the feature off entirely and generate the JS every time.

Updating summary because there is some code that gets re-used throughout Bugzilla and it would make sense to do this all now and not just limited to the query. Also, updating dependencies

The versioncache already stores a lot of information and is generated automatically when we modify a product; it would be easy to use the same mechanism to generate JS. The problem is the groupset issue. I can see two ways out: a) Generate a cache only for the public products. This isn't too hard to do, but it does present the problem that part of the data will come from a cache and part, from generated code. Not too good. b) Generate a cache for each groupset. I'm not too familiar with groups, but it seems this could be done, I guess, and would be more homogenous than a). So I think b is good. :)

I'm thinking it might be sensible to only keep the last X Javascripts, where X ~ 10 and is possibly customisable. I think it's quite important that the CGI allows proper caching, ie passes and interprets last-changed dates in headers and can return the "Not Changed" HTTP status code, which should speed up query page load time. I don't know everything about browser caching, but some people on #mozilla probably would.

What would happen if you just removed the <!-- and //--> delimiters from around the Javascript? Everyone seems to pop this little fetish into their code, but I should think browsers that display the contents of <script> are quite rare these days.

well that's an option I could live with as a temporary hack but the best solution really is to separate script from content where possible.

Adding dependency to 123030 which is going to be a quick move of the query.cgi js so we avoid duplicating code when bug 98801 lands.

Sigh. No time to work on this anymore... ->Default owner.

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)

What is this patch about nowadays? The description doesn't seem to fit with the summary. Are we keeping this as a tracker bug?

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.

Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.