The above url is just an example. But, suppose that you wanted to mark is as a dupe. To review, the steps to mark a dupe: 1. Load bug (obviously) 2. Click on INPUT for "Resolve bug, mark it as duplicate of bug" 3. Enter a bug number there. 4. Click the radio button that corresponds with "Resolve bug..." 5. Commit bug. However, through JavaScript, it would be possible to have the radio button automagically select itself whenever the user puts his/her cursor on the INPUT box, through using the onFocus function of INPUT. Of course, this functionality for set-as-duplicate is just an example. For instance, it could also be applied to the "Reassign bug to..." and "Change resolution to" fields. I'm concerned that I've written this explanation badly, so if this doesn't make sense, just say so ;-).

I'm not entirely sure what your asking for, but I think Bugzilla may already (sort of) do it. To see what I'm refering to: 1. Load any bug 2. Click in the box for "mark it as duplicate of bug #[ ] 3. Type a number 4. Click in the additional comments box (or anything except the radio buttons, Commit, or Reset

Jake: You're right , the current functionality is kinda close. However, I think it can be made even better :-). Currently, the INPUT tag is setup with the onChange event. With this, the event fires after the user changes the input and *then* clicks somewhere else (such as the "Additional Comments" box, as you mentioned). However, with that event changed to onFocus, instead, the radio button will be modified the moment the user clicks inside the INPUT box. (It's a relatively small change, but I think it's for the better)

I agree with Alex. This would be better with onFocus, and would cause less confusion that way. I've seen comments on other bugs from people who got confused because it didn't change until after they moved somewhere else, etc.

Making this change would cause data corruption for users who navigate the bug form with their keyboards. Tabbing through the "duplicate bug number" field (f.e. on the way to the "Commit" button) would cause the field to gain focus and the "Resolve bug as duplicate" radio button to be selected incorrectly. This would also happen when mouse users clicked in the field accidentally or clicked in the field and then changed their minds. This is a very bad thing from a user interface perspective. I recommend resolving WONTFIX. (And now I am going to TAB down to the "Commit" button as I am wont to do.)

Hmm, that's a good point. I never thought of that because I never use the tab key to move between form elements and links and such. Netscape 4 never let me do that and I got used to it. Taking that into consideration, I'd have to agree with Myk and WONTFIX this. (Which is a shame because it would have been cool for those that click on things, but he's right, it'll be even worse confusion for people who use the tab key)

Myk: You do make a good point. But, I think I may have a compromise. What about configuring onFocus, but then also using ACCESSKEYs to allow keyboard-users easy access to the form fields? ( The ACCESSKEY parameter -- for INPUT, HREF, and many other HTML tags -- allows the web author to define hotkeys for form-fields, links, and buttons. See here for an example: http://www.idocs.com/tags/forms/_INPUT_ACCESSKEY.html ) As a side note: Myk, how do you manage to use the keyboard so efficiently? When I tried to get down to the "Additional Comments" section of this page, it took me 44 presses of the Tab key.

To my experience, most browsers ignore the accesskey parameters if they create conflicts with hotkeys used by the browser itself and/or the OS. And since every browser and OS has a different set of hot keys, there's no way you'd ever be able to pick one that worked on all browsers.

>As a side note: Myk, how do you manage to use the keyboard so efficiently? I hold down the tab key until the focus border gets close to my target and then lift my finger and hit the key multiple times (or hold down the shift key and hit it if I overshot) until I get to my target. Despite the problems with this approach, it is still faster and less frustrating for me than reaching for my mouse.

Through reading the discussion on this bug, I accept that it would not be a good idea for everyone to have onFocus. So, I've filed bug 97348 requesting onFocus as a Bugzilla preference.

As per Myk's comments in bug 97348, I'm modifying this bug. Old summary: RFE: Use onFocus for INPUT to change radio button as well New summary: RFE: Use onKeyPress for INPUT to change radio button as well This approach offers the best of both words: merely tabbing "into" a text field changes nothing, yet the radio button changes the moment the bug reporter starts entering text.

As shown on the testpage (see attachment), even keys such as Tab, Shift, and Ctrl generate onKeyPress events. So, the Javascript would have to ensure to disregard those keys (or, in reverse, only accept letter/number keys).

Actually, the algorithm is much simpler. On key press, check the length of the text field. If length>0, record the current state of the radio button and then change it to "resolve duplicate". If length==0, change the radio button back to its previous setting if it has one.

That check-for-length algorithm does work for the "Mark as duplicate..." field. However, if this onKeyPress functionality is also used with other radio buttons such as "Reassign bug to", then a different algorithm might be needed (since "Reassign bug to" has a default value which is > 0 chars).

hmm, there's a bug filed somewhere (don't recall the number offhand, and I need to run, so I don't have time to look for it right now) for the reassign-to thing for making it not change if you change it back to the original value or make it blank before exiting the field....

See also bug 76161 and bug 52885.

onkeypress is not the correct event, because it doesn't trigger on right-click pastes, drags, etc. You want oninput, which is like onchange but doesn't wait for the user to "finish" making the change. If enough browsers support oninput, we could even replace the onchange with an oninput.

Jesse: oninput sounds similar to onfocus (?). However, onfocus was shot-down in comment #4 :-/.

Oninput is safe because it does not fire unless you change the text in the field. Try this URL: data:text/html,<input type=text oninput="alert(5)">

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being retargeted to 2.20 If you plan to act on one immediately, go ahead and pull it back to 2.18.

This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.

Radio buttons are gone since Bugzilla 3.2.