Closed Bug 452734 Opened 16 years ago Closed 16 years ago

Remove the keyword chooser, because it's a usability regression

Categories

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

Tracking

()

RESOLVED FIXED
Bugzilla 3.2

People

(Reporter: tonymec, Assigned: mkanat)

References

()

Details

(Keywords: access, regression)

Attachments

(3 files, 12 obsolete files)

21.22 KB, image/png
Details
10.44 KB, image/jpeg
Details
25.70 KB, patch
LpSolit
: review+
Details | Diff | Splinter Review
Since update to Bugzilla 3.2, keywords cannot be entered by just typing them in anymore.

This is IMO a major regression. Among the umpteen zillion available keywords, there are maybe a handful or less that I commonly use, mostly just "crash", "hang" and/or "regression".

The "right" way to ease the input of keywords would IMHO have been autocomplete: let's say I type cr into the Keywords box, and a drop-down list appears below, with "crash" available to be selected.
use noscript :)

this feature was stupid.

ignoring that, at the very least you *must* call .focus() otherwise it takes zillions of <tab> presses to reach the widget (which is in tab order, but just not remotely local).
Keywords: access
Depends on: 80169
(In reply to comment #1)
> this feature was stupid.

This feature is not stupid at all, and is very useful. In case you didn't notice, you can click in the drop-down list and start typing your keyword. It will automatically select it. So you can still work as you did till now.
Severity: major → minor
Keywords: regression
(In reply to comment #2)
> (In reply to comment #1)
> > this feature was stupid.
> 
> This feature is not stupid at all, and is very useful. In case you didn't
> notice, you can click in the drop-down list and start typing your keyword. It
> will automatically select it. So you can still work as you did till now.

Well, no, I hadn't noticed it. In most drop-downs, if I type cr it'll select the first keyword starting with c then the first one starting with r.

With such an awfully long list of possibilities, I'm still of the opinion that showing the list within such a short window is not useful, that the possibility to reach the desired keyword by typing more than one letter of its name is not discoverable, and that autocompletete would be better in both respects. (And remember that some features, such as the throbber link, have been removed not so long ago on the only argument that they supposedly weren't "discoverable".)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
(In reply to comment #2)
> This feature is not stupid at all, and is very useful. In case you didn't
> notice, you can click in the drop-down list and start typing your keyword. It
> will automatically select it. So you can still work as you did till now.

Um, this really really really sucked for anyone who deals with branch triage and has to type "fixed1.8.1.17" which I often bork. You're adding extra clicks all around for no real reason.

This is my #1 complaint about the new bugzilla... and believe me, I have many complaints. This is, by far, the most hindering change that was made. This might be wonderful for *other bugzillas* but not for ours.

--

Oh, awesome. I bet Smokey resolved this bug by accident because of another of my hated changes with this release...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yeah, this is a usability regression. That you have to click around a bunch where you used to be able to just paste or quickly type something in slows me down a lot. AJAX autocomplete might be useful, but any UI that requires clicks or excessive tabbing is going to slow me down.
Yeah, I certainly didn't intend to mark this FIXED.  It breaks pasting multiple keywords, which is annoying, and turns a 5-second typing exercise into a 30-second mousing one, which is wasteful.  From a UI perspective, what *looks* like a text field apparently is not; you can't type in it, you can't select stuff in it, and you can't tab into it; it has absolutely no properties of a text field.

Those of us who need to use keywords know what they are (and when we don't, know how to use the link to the keyword list to find them), and this change seriously impedes our workflow while providing absolutely no benefit.  (People who don't need to use keywords...well, don't need to use them.)
(In reply to comment #5)
> Yeah, this is a usability regression. [...]

Don't know why Frédéric removed my regression keyword when he added comment #2. This is a bug which was not present in the present release, we know exactly at which step it was introduced. As the keyword description says, "problems outside those identified in precheckin and smoke tests that were found in current builds that were known to be working in previous builds".
Keywords: regression
(In reply to comment #2)
> notice, you can click in the drop-down list and start typing your keyword. It
> will automatically select it. So you can still work as you did till now.

Not really.

Before:
 - tab into field
 - type "fixed1.9.0.2"
 - tab out of field

Now:
 - tab into field
 - focus moves sloshbucket
 - start typing, no immediate feedback when there's collisions
 - eventually you're highlighting your keyword
 - tab to the arrow, press space
 - tab over to the ok button, press space

While I agree that it's more helpful than entering keywords and getting a big red screen, this isn't the right UI.

What you want is some JS that does autocomplete, matching against existing keywords. It needs to allow multiple keywords per field. See the "to" field of a Gmail message compose for an example.
No longer depends on: 452812
Attached image overdraw?
I clicked the keyword field and thought I'd hit a Firefox bug. :(
Attached image no overdraw
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080829033406 SeaMonkey/2.0a1pre

maybe you did? This is what it looks to me
I saw what shaver saw for a while (missing border around the popup elements), but it seems back to what it was last night.

I can't seem to get it to work without mouse-clicking focus into the keyword
picker that shows up after mouse-clicking in the keyword field itself. And then
there's no feedback that I'm typing the right stuff, and with a zillion
"fixed1234" keyword to match against I've got to type a lot before I find out
that I went wrong and am not going to get my match.

The drop-down seems aimed at people who don't know what the right keywords are,
but in that case they'll need more than just the name shown in the box to get
it right. The Keywords label is a link to names *and* descriptions, which is
what those people are going to need. For people who do know what they want the
drop-down is usability hell.
(In reply to comment #8)
> Now:
>  - tab into field
>  - focus moves sloshbucket
>  - start typing, no immediate feedback when there's collisions
>  - eventually you're highlighting your keyword
>  - tab to the arrow, press space
>  - tab over to the ok button, press space

This isn't what I see at all on my mac. I get:

 - tab into keywords field
 - popup appears
 - start typing, nothing happens
 - Try to tab to keyword list, focus moves to the Depends links, but hidden behind the still visible popup.
 - Give up and click on the keyword list...
Anyone got a greasemonkey that fixes this?  It's earthshatteringly annoying.
This is a very bad regression... I should still be able to type into the keywords field.
Severity: minor → major
Flags: blocking3.2?
Not a handy feature.
You can type "regression, testcase" within one second but the new select box costs about 10 seconds. Even in case you mistype the keyword, the error page plus the correction is faster than the select box.
(In reply to comment #13)
> Anyone got a greasemonkey that fixes this?  It's earthshatteringly annoying.

I just made some. http://fredericiana.com/2008/08/29/bugzilla-32-remove-keyword-chooser-user-script/
Anybody saying that this feature is useful should notice the vast number of people here commenting that it is *not* useful to them.

I can confirm that it is generally not useful to me, particularly on a large set of keywords.

However, abuse, insults, or authoritarian statements are absolutely the worst way to get a bug fixed. If anybody would like to see this bug stay open forever, please use words like "stupid" or "must".

With all that said, I would be entirely fine with *removing* the keyword chooser, particularly as it uses a bunch of custom JS and not YUI. Barring that, we should make it possible to type into the field in addition to what we see there.

This is not a blocker for an upstream release, as there are no other installations (that I am aware of) that make as heavy use of keywords as bmo does. However, I'd take some fix for it on the 3.2 branch.
Flags: blocking3.2? → blocking3.2-
Target Milestone: --- → Bugzilla 3.2
Also, I'd like to make a note here that what matters in a UI is not its theoretical usability, but its practical usability in the situations that it's being used in. Sometimes the theoretical usability has a value (particularly when your users have been indoctrinated into a bad UI that you now must indoctrinate them out of, which we certainly have plenty of in Bugzilla), but mostly I care about whether or not the system can actually be used by the people who are using it.

Granted, there are many different types of users, and the users who comment in bugs like this only represent one or two groups of users. However, for this particular feature, it's only that group of users that matters--they're really the only people who actively use the keywords field (as opposed to just reading it).
I concur:
a "fool proof" UI is just fine, but why disable the "power user" / direct UI ??
I'll fix it.
Assignee: create-and-change → db48x
I've got a test install up on landfill at <https://landfill.bugzilla.org/keywordpicker/>; I'd appreciate it if you guys could give it a spin and see what you think so far.
(In reply to comment #23)
> I've got a test install up on landfill at
> <https://landfill.bugzilla.org/keywordpicker/>; I'd appreciate it if you guys
> could give it a spin and see what you think so far.

I like how typing works again, and how it adds keywords from the left to the right list instantly when you type them.

I dislike how it's not helping you at all (any type of autocomplete would be terrific).
Attached patch 452734-1.diff (obsolete) — Splinter Review
This patch allows the user to type keywords in the textbox to drive the selection ui. Also hides the selection ui when the user moves the focus away from the textbox.
Attachment #336202 - Flags: review?(mkanat)
Attachment #336202 - Attachment is patch: true
Attachment #336202 - Attachment mime type: application/octet-stream → text/plain
Status: REOPENED → ASSIGNED
Comment on attachment 336202 [details] [diff] [review]
452734-1.diff

>Index: js/keyword-chooser.js
[snip]

  This all looks fine. Don't worry about your TODOs, eventually we'll probably replace this thing with YUI autocomplete or something like that which will do all those things automatically. Did you test this in IE, Safari, and Opera?

>Index: template/en/default/bug/keyword-chooser.html.tmpl
>+        <select id="keyword-list" size="8" multiple style="font-size: smaller;">

  No style=, please. put it in skins/standard/show_bug.css

>+        <select id="bug-keyword-list" size="8" multiple style="font-size: smaller;">

  And here too.

>+  var validKeywords = [[%- FOREACH kwd = valid_keywords -%]"[% kwd FILTER html %]", [%- END -%]];

  Doesn't IE have a fit about trailing commas? I forget.
Attachment #336202 - Flags: review?(mkanat) → review-
  Oh, also, that very last FILTER html needs to be FILTER js.
(In reply to comment #24)
> I dislike how it's not helping you at all (any type of autocomplete would be
> terrific).

Indeed, if you type a unique prefix of one of the items in the list, then type a comma or a space, it should complete it for you.

(In reply to comment #26)
> (From update of attachment 336202 [details] [diff] [review])
> >Index: js/keyword-chooser.js
> [snip]
> 
>   This all looks fine. Don't worry about your TODOs, eventually we'll probably
> replace this thing with YUI autocomplete or something like that which will do
> all those things automatically. Did you test this in IE, Safari, and Opera?

The TODOs are mostly just ideas that I had; I'd hate to have a good idea and then forget about it. As for testing in other browsers, nope, I haven't! I did, however, avoid doing a few things that IE can't do, such as Array.map.

> 
> >Index: template/en/default/bug/keyword-chooser.html.tmpl
> >+        <select id="keyword-list" size="8" multiple style="font-size: smaller;">
> 
>   No style=, please. put it in skins/standard/show_bug.css

Ok.

> 
> >+  var validKeywords = [[%- FOREACH kwd = valid_keywords -%]"[% kwd FILTER html %]", [%- END -%]];
> 
>   Doesn't IE have a fit about trailing commas? I forget.

Sorta. It adds an extra undefined item at the end of the list, but the rest of the code doesn't care about that.
(In reply to comment #27)
>   Oh, also, that very last FILTER html needs to be FILTER js.

Ah, good point.
Attached patch 452734-2.diff (obsolete) — Splinter Review
Attachment #336202 - Attachment is obsolete: true
Attachment #336204 - Flags: review?(mkanat)
Attachment #336204 - Flags: review?(mkanat)
Comment on attachment 336204 [details] [diff] [review]
452734-2.diff

Oops, silly me. There's an obvious bug.
Attached patch 452734-3.diff (obsolete) — Splinter Review
Ok, this patch is pretty well complete. Focusing other form fields works quite well (in the last patch focusing an element inside the popup would dismiss the popup as well), and you don't have to type the entire keyword for it to be selected, as long as what you've typed uniquely matches a single keyword.
Attachment #336204 - Attachment is obsolete: true
Attachment #336212 - Flags: review?(mkanat)
Attached patch 452734-4.diff (obsolete) — Splinter Review
handles escape and enter in the textbox, as per comments from pyrzak on irc
Attachment #336212 - Attachment is obsolete: true
Attachment #336213 - Flags: review?(guy.pyrzak)
Attachment #336212 - Flags: review?(mkanat)
Attachment #336213 - Flags: review?(guy.pyrzak) → review?(mkanat)
Oh, and just a note: I changed the style of the KeywordChooser object so that some of the methods and variables became private.
The one thing I noticed from whatever version of your patch is currently on your landfill install is that deleting (and by extension selecting all and then pasting) a keyword in the text field doesn't remove the keyword from the list in the picker (and thus ultimately from the keyword field).

It therefore prevents "delete and return" or "delete and unfocus" or whatever, so to actually remove a keyword you have to enter the picker and select the keyword to remove and use the arrows to move it back to the left column, etc.

Removing keywords isn't *as* common as adding them, put it's still pretty common: replacing "fixedFoo" with "verifiedFoo", removing "fixedFoo" when a patch is backed out/bug reopened, removing "regression" when something's found not to be a regression, removing qawanted, etc.  (When we get the testcase-wanted keyword, that'll get replaced often with "testcase" when someone adds a testcase.)
I added this comment to the wrong bug somewhere, but I don't know which bug:

  If we're going to write so much custom JS, can we just look into using YUI for the keyword chooser?
I didn't look at the patch, but does it implement the suggestion made at http://fredericiana.com/2008/08/29/bugzilla-32-remove-keyword-chooser-user-script/ ? I think that's the way to go (i.e. the autocomplete/suggestion feature).
(In reply to comment #35)
> The one thing I noticed from whatever version of your patch is currently on
> your landfill install is that deleting (and by extension selecting all and then
> pasting) a keyword in the text field doesn't remove the keyword from the list
> in the picker (and thus ultimately from the keyword field).

Yes, but that's only because I've broken it slightly while trying to get it to work in IE.

(In reply to comment #36)
>   If we're going to write so much custom JS, can we just look into using YUI
> for the keyword chooser?

Yes. Unfortunately I didn't know that bugzilla was using YUI, so I didn't know to use it. Also, I've never used it before, so I'd rather get this patch checked in first.
(In reply to comment #37)
> I didn't look at the patch, but does it implement the suggestion made at
> http://fredericiana.com/2008/08/29/bugzilla-32-remove-keyword-chooser-user-script/
> ? I think that's the way to go (i.e. the autocomplete/suggestion feature).

It is essentially an autocomplete widget, yes.
Attached patch keyword example (obsolete) — Splinter Review
check it out, let me know what you think. Just dave, if you could put it somewhere where people could play around with it I'd appreciate it. There is more I could do, this is just a first cut.
pyrzak, with your patch, if you have only one keyword and you click the keyword field, the keyword is automatically selected and you have no way to delete it.

I have to go now; I will test it more later today. :)
(In reply to comment #40)
> Created an attachment (id=336313) [details]
> keyword example
> 
> check it out, let me know what you think. Just dave, if you could put it
> somewhere where people could play around with it I'd appreciate it. There is
> more I could do, this is just a first cut.

Cool. Do you have a landfill instance for it?
Attached patch Mozilla version of the patch (obsolete) — Splinter Review
Attachment #336369 - Attachment is obsolete: true
Attached patch Mozilla version of the patch V4 (obsolete) — Splinter Review
this has a few tweaks: no longer uses commas and reacts much faster to timing
Attached patch Mozilla version of the patch V5 (obsolete) — Splinter Review
Attachment #336371 - Attachment is obsolete: true
Attachment #336379 - Attachment is obsolete: true
Attachment 336380 [details] [diff] is live on bugzilla-stage-tip, and has been committed to the bmo bzr repo.  I will probably deploy it to production shortly, since this has been a high-contention issue. :)
Oh, the new keyword auto-completion on bmo is fantastic!
YES!  So much better.

Huge kudos on the quick fix, and thanks. (as much as I hate to see "me too" posts in BMO, it seems some applause is warranted here, to offset the previous grumbling -- my own, included).

Thanks.
Tabbing through the keywords file with no keywords already filled is still sub-optimal: It insists on filling in 4xp when tabbing out if you don't hit Esc before. It also fills in 4xp several times if you hit Tab, Backspace, Tab with originally no keywords filled in...

Daniel, Guy: New bug - or are you still working on it in here?
Keywords: access, regression4xp
We don't need a proof of concept. Leave the keywords field alone, please. :)
Keywords: 4xpregression
Any chance we can tweak the skin slightly? The yui-ac-input class has a width which overrides the size attribute :-( When I looked earlier the absolute position also had an unwanted effect but I no longer see that.
(In reply to comment #50)
> Daniel, Guy: New bug - or are you still working on it in here?

I imagine that reporting problems with the version that got checked in to bugzilla.mozilla.org here is fine, since that was an early version that wasn't fully polished yet.

Also, I kinda like my version better; even though the UI it created is clunkier, the behavior when you type in it is superior. Also, it didn't replace the built in history provided by the browser. I hope those can be improved in the YUI version, because I'm not sure I want to spend a whole lot more time getting my version to work in IE.
Yes, I have read comment #48 and comment #49, but as reporter of this bug I feel a certain responsibility. This new autocomplete widget seems to use mostly or only my browser's form history, at least on the create-bug page (full form). This looks almost ideal to me, and I'm tempted to declare this bug FIXED, but on second thought I think I'll leave that job to the assignee, if and when he decides he likes it. Good job, Daniel. ;-)
Depends on: 453389
turns out the keyword autocomplete is broken on the create page. So what you're saying is "I just want the old UI back". I'm going to assume the fix for all the people who dislike losing their browser auto complete etc is to make it a pref or use daniel's UI changes
(In reply to comment #55)
> turns out the keyword autocomplete is broken on the create page. So what you're
> saying is "I just want the old UI back". I'm going to assume the fix for all
> the people who dislike losing their browser auto complete etc is to make it a
> pref or use daniel's UI changes

I can't use Greasemonkey (comment #17) because it won't install on SeaMonkey 2.0a1pre; I've tried adapting the (one-line) Greasemonkey script to write an MR-Tech userChrome.js script but got nowhere (I guess I don't know Javascript well enough); and since then I've had to disable MTT anyway because it was interfering with my add-ons manager. But I digress.

I've seen the autocomplete on show_bug.cgi (with autocomplete from the "official" keywords regardless of my form history) and that interface is OK for me too. I haven't tried copying from it or pasting to it, but I guess they work again now.

Making it a pref would be nice too, and I suppose it would allow the people (if any) who want the double-list UI to get it too as an alternative. I'm not against people using a UI that I hate as long as they don't force it on me. :-)
No longer depends on: 453389
I'm confused how bug 453389 can possibly be a duplicate of this bug, since the problem that bug describes is not mentioned anywhere in here...  At least one would think the duplicator would have the decency to move the information over...

In any case, the relevant parts are:

> From  Boris Zbarsky (todo: 200+ items)   2008-09-02 18:04:53 PDT

STEPS TO REPRODUCE:

1) Start with a bug in Core which has the keywords "qawanted" and "regression"
   on it (so that the Keywords field contains the text "qawanted,
   regression").  The goal is to remove the "qawanted" keyword.
2) Double-click on "qawanted"
3) Press delete
4) Hit the right arrow key (so that you can try to delete the comma)

EXPECTED RESULTS: The caret moves one spot to the right, letting you delete the
comma.

ACTUAL RESULTS: The "4xp" keyword is added to the textfield, so that now the
text says ", regression 4xp" with the caret positioned all the way at the end.

NOTE: The textfield also eats the Ctrl-k keystroke (which should delete
everything in it).  I guess I should file that as a separate bug?

> From  Tony Mechelynck   2008-09-02 20:09:00 PDT

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080902011844
SeaMonkey/2.0a1pre

I'm changing the platform to PC/All (meaning at least two of Intel-Mac,
Linux-i686 and W32) because I see something similar on Linux (using the
keywords on this bug even though it is not a Core bug):

Double-clicking "qawanted" highlights it with the comma and space, and I can
easily delete it. BUT: if I place the text cursor just before the comma then
hit Shift-Home (to highlight only "qawanted" without the comma) and hit Del
(leaving the comma) then if I hit the right-arrow it adds " 4xp" at far right,
leaving the comma and space at far left, just as said in comment #0. I call
this "reproducing the bug" using a slightly modified procedure.

If I want to delete the 4xp I have to do it without hitting Left (or a second
4xp gets added) e.g. by clicking the mouse just right of "regression" then
hitting Shift-End then Del

If I place the cursor at far left (before the comma) and type qawanted, what I
get in the autocomplete box is not qawanted but... "regression" and
"regressionwindow-wanted"!
New behaviour on production bugzilla.mozilla.org is a lot nicer, thanks for the quick fix, drivers really really appreciate it.
In reply to comment #58 by Boris Zbarsky:
Boris, some people believe that the recent changes and changes-again to the keywords UI (as of the present bug) are what inadvertently caused the behaviour you noticed. I suppose that if the arrow keys are still mishandled after this bug is declared FIXED, it will then be time to REOPEN bug 453389. The other possibility is that now that the assignee of the present bug has been made conscious of the misfeature you noticed, he'll make sure to adjust his patch accordingly. Let's wait and see. :-)
Since I'm going to have to either make tweaks to the YUI auto-complete UI or fix Daniel's UI so it works in IE, I'm going to take this bug.

Here are my plans for this thing:
0. Fix the "bug" on the create page (the auto-complete doesn't work at all, which I know some of you prefer :D )
1. Make the auto-complete a user pref, turned on by default.
2. Make it super easy to turn off with greasemonkey or similar things.
3. Attempt to futz with the YUI code or contact the YUI guys and see if there are things I can do to address your concerns:
  * tabbing through the fields doing strange stuff
  * Losing the browsers "autocomplete" to fill in fields with info you've already filled in
  * Arrow Keys doing stuff you're not familiar with
  * Look into doing something helpful to make auto-complete also auto-narrow with some meta key combo, kinda like bash, but NOT with tab (extra credit)
4. If those attempts fail or require more code than Daniel's UI, revert to Daniel's version and make it work with IE and other browsers.

Thanks to everyone who is pointing out weird interactions with the YUI auto-complete, my apologies for this not being a spick and span patch, we're doing our best to fix it, just realize we're doing this in our spare time.
Assignee: db48x → guy.pyrzak
Guy's patch requires a newer version of YUI, something that we will not take on a stable branch. I think the correct upstream solution for now is to entirely remove the keyword picker, as all other solutions require too much code on a stable branch. Guy--could you file a separate bug that removes the keyword chooser for 3.2 (including removing the mention of it from the Release Notes)?
Priority: -- → P1
Attachment #336213 - Attachment is obsolete: true
Attachment #336313 - Attachment is obsolete: true
Attachment #336380 - Attachment is obsolete: true
Attachment #336792 - Flags: review?(mkanat)
Attachment #336213 - Flags: review?(mkanat)
Attachment #336792 - Attachment is patch: true
Attachment #336792 - Attachment mime type: application/octet-stream → text/plain
Attachment #336784 - Attachment is obsolete: true
Comment on attachment 336792 [details] [diff] [review]
removes keyword chooser from bugzilla

You also need to remove the actual keyword-chooser.js file. (And check the original patch too for anything else that you might have to remove, if that's not how you made this patch.)
Attachment #336792 - Flags: review?(mkanat) → review-
this is based on the current bugzilla head ( i did a cvs -q up -dCP)
Attachment #336792 - Attachment is obsolete: true
Attachment #336803 - Flags: review?(mkanat)
Comment on attachment 336803 [details] [diff] [review]
removes keyword chooser from bugzilla v2

There's a bunch of other stuff that needs to be removed. See the last patch on bug 80169.
Attachment #336803 - Flags: review?(mkanat) → review-
(In reply to comment #62)
> Guy's patch requires a newer version of YUI, something that we will not take on
> a stable branch.

Why not? What's the problem with taking a new version of YUI on 3.2 as it's included in the tarball (except the bfcache problem)? I would understand if that was an external dependency, but that's not the case here.
The keyword chooser must be removed before we release 3.2. The autocomplete patch will land into 3.4 only.
Flags: blocking3.2- → blocking3.2+
I was happy to work on this when it was improving the UI, I don't feel qualified, nor have the desire to remove all the keyword stuff from all the cgi, template etc. Assigning it back to the default, feel free to take it.
Assignee: guy.pyrzak → create-and-change
Assignee: create-and-change → guy.pyrzak
Assignee: guy.pyrzak → create-and-change
Okay, this removes everything I could find related to the keyword chooser. I did some basic testing, and things seem to still be working fine, and runtests passes.
Assignee: create-and-change → mkanat
Attachment #336803 - Attachment is obsolete: true
Attachment #338231 - Flags: review?(LpSolit)
Comment on attachment 338231 [details] [diff] [review]
Remove Chooser: v3

Seems to work fine. I tested on tip only, but I guess it applies cleanly on the 3.2 branch too. r=LpSolit
Attachment #338231 - Flags: review?(LpSolit) → review+
Updating the bug summary to better reflect what the last patch does. We will need a separate bug to implement the keyword autocomplete feature. mkanat, could you file this new bug?
Summary: Since update to Bugzilla 3.2, keywords cannot be entered by just typing them in anymore → Remove the keyword chooser
Summary: Remove the keyword chooser → Remove the keyword chooser, because it's a usability regression
The new bug is bug 455810.

The 3.2 patch required a tiny adjustment to apply correctly to globals.css, but otherwise it applied fine.

tip:

Checking in attachment.cgi;
/cvsroot/mozilla/webtools/bugzilla/attachment.cgi,v  <--  attachment.cgi
new revision: 1.149; previous revision: 1.148
done
Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.385; previous revision: 1.384
done
Checking in enter_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v  <--  enter_bug.cgi
new revision: 1.164; previous revision: 1.163
done
Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v  <--  post_bug.cgi
new revision: 1.198; previous revision: 1.197
done
Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.414; previous revision: 1.413
done
Checking in show_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/show_bug.cgi,v  <--  show_bug.cgi
new revision: 1.55; previous revision: 1.54
done
Removing js/keyword-chooser.js;
/cvsroot/mozilla/webtools/bugzilla/js/keyword-chooser.js,v  <--  keyword-chooser.js
new revision: delete; previous revision: 1.3
done
Checking in js/util.js;
/cvsroot/mozilla/webtools/bugzilla/js/util.js,v  <--  util.js
new revision: 1.4; previous revision: 1.3
done
Checking in skins/standard/global.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/global.css,v  <--  global.css
new revision: 1.51; previous revision: 1.50
done
Checking in template/en/default/filterexceptions.pl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v  <--  filterexceptions.pl
new revision: 1.117; previous revision: 1.116
done
Checking in template/en/default/attachment/created.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/created.html.tmpl,v  <--  created.html.tmpl
new revision: 1.22; previous revision: 1.21
done
Checking in template/en/default/attachment/updated.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/updated.html.tmpl,v  <--  updated.html.tmpl
new revision: 1.20; previous revision: 1.19
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--  edit.html.tmpl
new revision: 1.133; previous revision: 1.132
done
Removing template/en/default/bug/keyword-chooser.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/keyword-chooser.html.tmpl,v  <--  keyword-chooser.html.tmpl
new revision: delete; previous revision: 1.3
done
Checking in template/en/default/bug/show.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.html.tmpl,v  <--  show.html.tmpl
new revision: 1.26; previous revision: 1.25
done
Checking in template/en/default/bug/create/create.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create.html.tmpl,v  <--  create.html.tmpl
new revision: 1.86; previous revision: 1.85
done
Checking in template/en/default/bug/create/created.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/created.html.tmpl,v  <--  created.html.tmpl
new revision: 1.14; previous revision: 1.13
done
Checking in template/en/default/bug/process/header.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/header.html.tmpl,v  <--  header.html.tmpl
new revision: 1.11; previous revision: 1.10
done
Checking in template/en/default/list/edit-multiple.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/edit-multiple.html.tmpl,v  <--  edit-multiple.html.tmpl
new revision: 1.51; previous revision: 1.50
done
Checking in template/en/default/list/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v  <--  list.html.tmpl
new revision: 1.62; previous revision: 1.61
done

3.2:

Checking in attachment.cgi;
/cvsroot/mozilla/webtools/bugzilla/attachment.cgi,v  <--  attachment.cgi
new revision: 1.144.2.2; previous revision: 1.144.2.1
done
Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.374.2.4; previous revision: 1.374.2.3
done
Checking in enter_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v  <--  enter_bug.cgi
new revision: 1.160.2.3; previous revision: 1.160.2.2
done
Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v  <--  post_bug.cgi
new revision: 1.196.2.1; previous revision: 1.196
done
Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.410.2.1; previous revision: 1.410
done
Checking in show_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/show_bug.cgi,v  <--  show_bug.cgi
new revision: 1.53.2.1; previous revision: 1.53
done
Removing js/keyword-chooser.js;
/cvsroot/mozilla/webtools/bugzilla/js/Attic/keyword-chooser.js,v  <--  keyword-chooser.js
new revision: delete; previous revision: 1.3
done
Checking in js/util.js;
/cvsroot/mozilla/webtools/bugzilla/js/util.js,v  <--  util.js
new revision: 1.3.2.1; previous revision: 1.3
done
Checking in skins/standard/global.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/global.css,v  <--  global.css
new revision: 1.47.2.3; previous revision: 1.47.2.2
done
Checking in template/en/default/filterexceptions.pl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v  <--  filterexceptions.pl
new revision: 1.111.2.2; previous revision: 1.111.2.1
done
Checking in template/en/default/attachment/created.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/created.html.tmpl,v  <--  created.html.tmpl
new revision: 1.21.2.1; previous revision: 1.21
done
Checking in template/en/default/attachment/updated.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/updated.html.tmpl,v  <--  updated.html.tmpl
new revision: 1.19.2.1; previous revision: 1.19
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--  edit.html.tmpl
new revision: 1.125.2.8; previous revision: 1.125.2.7
done
Removing template/en/default/bug/keyword-chooser.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/Attic/keyword-chooser.html.tmpl,v  <--  keyword-chooser.html.tmpl
new revision: delete; previous revision: 1.3
done
Checking in template/en/default/bug/show.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.html.tmpl,v  <--  show.html.tmpl
new revision: 1.25.2.1; previous revision: 1.25
done
Checking in template/en/default/bug/create/create.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create.html.tmpl,v  <--  create.html.tmpl
new revision: 1.83.2.3; previous revision: 1.83.2.2
done
Checking in template/en/default/bug/create/created.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/created.html.tmpl,v  <--  created.html.tmpl
new revision: 1.13.2.1; previous revision: 1.13
done
Checking in template/en/default/bug/process/header.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/header.html.tmpl,v  <--  header.html.tmpl
new revision: 1.10.2.1; previous revision: 1.10
done
Checking in template/en/default/list/edit-multiple.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/edit-multiple.html.tmpl,v  <--  edit-multiple.html.tmpl
new revision: 1.49.2.2; previous revision: 1.49.2.1
done
Checking in template/en/default/list/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v  <--  list.html.tmpl
new revision: 1.59.2.1; previous revision: 1.59
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago16 years ago
Flags: approval3.2+
Flags: approval+
Resolution: --- → FIXED
Blocks: 500436
You need to log in before you can comment on or make changes to this bug.