457116 - initKeywords should reside in an external script, not be included in every page

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, defect)

Description

[Simon Bünzli]

Currently, every page containing the keywords chooser is 36K bigger than it need be (that's 1/3 to 1/4 of the whole download for a reasonably sized bug). Why not allow browsers to cache the keyword list at least for a few hours before refetching it?

Should keywords differ by product or user, that information could still be part of the dynamically generated script's path or arguments.

BTW: The keywords list is also unnecessarily included when the user isn't logged in, just costing bandwidth.

BTW2: On this enter_bug page, the keyword list is missing the explanations (and the chooser isn't working at all). Has this already been filed?

Comment 1

[Tony Mechelynck [:tonymec]]

- The keywords chooser has definitely been dropped, see bug 452734. If you see one, hit Shift+Ctrl+R
- The keywords input box will be improved, see bug 455810.
- The keyword list, with explanations, is reached from enter_bug.cgi ("full" form) by clicking the "Keywords" link: https://bugzilla.mozilla.org/describekeywords.cgi -- OTOH, the "guided" form has no "keywords" entry, anyone using it has to enter any desired keywords after the bug is filed.

Comment 2

[Simon Bünzli]

(In reply to comment #1)
> If you see one, hit Shift+Ctrl+R

After that, please hit Ctrl+U and see that those 36K of code are still there.

> - The keywords input box will be improved, see bug 455810.

Apparently, we're already running some of that code here on b.m.o. Moving this bug to that effect.

> - The keyword list, with explanations

Please enter a keyword on this very bug and hover over the autocomplete suggestion. There's the explanation I'm talking about...

Comment 3

[Simon Bünzli]

(In reply to comment #2)
> Please enter a keyword on this very bug and hover over the autocomplete
> suggestion. There's the explanation I'm talking about...

Scratch that. Apparently this feature has been broken somewhere along the line.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to comment #3)
> (In reply to comment #2)
> > Please enter a keyword on this very bug and hover over the autocomplete
> > suggestion. There's the explanation I'm talking about...
> 
> Scratch that. Apparently this feature has been broken somewhere along the line.

works for me :)
btw, this is an excellent suggestion.

OT but performance related, I changed my 25+ saved searches to not be displayed in the footer and my bz response time noticeably improved

Comment 5

[Frédéric Buclin]

Not including keyword descriptions would highly decrease the size of the page. If someone doesn't understand what a keyword means, he can click the "Keywords" label to go to describekeywords.cgi. Would someone object to remove descriptions?

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to comment #5)
> Not including keyword descriptions would highly decrease the size of the page.
> If someone doesn't understand what a keyword means, he can click the "Keywords"
> label to go to describekeywords.cgi. Would someone object to remove
> descriptions?

Not me. What about you, Simon? Wayne? Someone else?

In fact, when I think there's a keyword I should use but I'm not sure which one, I scan describekeywords.cgi anyway. Otherwise either I know which keyword to use (and add it) or I don't even know there is one (and don't look for one), so the only "descriptions" I ever use are those in describekeywords.cgi.

Comment 7

[timeless]

Load describekeywords.cgi in an iframe w/ #keywordname. There's no reason to reinvent the page or not show it.

if the anchor or poorly placed, then we should fix that :)

Comment 8

[Wayne Mery (:wsmwk)]

I can't speak to the coding. However, I question how useful this is as currently provided:
- discoverability isn't outstanding 
   * when one starts typing, the mouse is in the text box, not over the suggested autocomplete item
   * will most people mouseover an item in the selection list long enough to discover the description?
   * mouseover info is only provided if the mouse is over the TEXT of the line
- as noted in bug 453459 comment 63, this table is sent regardless of whether it's useful to the user, i.e. to users whose privs are less than editbugs

So, if it is to be retained, it would be far more useful if mouseover worked 
a) for all types of users, i.e. those without privs and when user is not logged in
b) when mouse in ANY part of a selection item's line

Comment 9

[Simon Bünzli]

(In reply to comment #5)
> Not including keyword descriptions would highly decrease the size of the page.

It still wouldn't allow caching the list, though.

> Would someone object to remove descriptions?

If the only reason is not having to correctly fix this bug, sure. ;-)

(In reply to comment #3)
> Apparently this feature has been broken somewhere along the line.

It really hasn't - that's the third * and suggestion b) of comment #8...

Comment 10

[Reed Loden [:reed]]

I just ripped out the keyword chooser in bug 577372 to prepare for the backporting of the new keyword autocomplete hotness from 4.0. Therefore, this will no longer be an issue once Bugzilla 3.6 launches on bmo (this week, most likely).