96983 - Move ALL Bugzilla javascript into separate file(s)

Status: ASSIGNED

(Bugzilla :: Bugzilla-General, enhancement, P1)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Target same as 47251.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 3

[Christian Reis]

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

Comment 4

[Dave Miller [:justdave]]

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.

Comment 5

[Christian Reis]

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

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 7

[Christian Reis]

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?

Comment 8

[Matthew Tuck [:CodeMachine]]

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.

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 10

[Christian Reis]

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

Comment 11

[Matthew Tuck [:CodeMachine]]

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.

Comment 12

[Christopher Hoess (gone)]

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.

Comment 13

[Christopher Aillon (sabbatical, not receiving bugmail)]

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. 

Comment 14

[Christian Reis]

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.

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 16

[Dave Miller [:justdave]]

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)

Comment 17

[Christian Reis]

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

Comment 18

[Dave Miller [:justdave]]

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.

Comment 19

[Dave Miller [:justdave]]

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.

Comment 21

[Reed Loden [:reed]]

In order to fully-implement CSP (bug 600692), Bugzilla needs to have all its inline JavaScript moved to external files. Bug 624212, comment #1 lists all the known <script> tags that need to be moved externally.

Comment 22

[Frédéric Buclin]

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.