96990 - RFE: Use onKeyPress for INPUT to change radio button as well

Status: RESOLVED WORKSFORME

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Description

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 1

[Jacob Steenhagen]

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

Comment 2

[Ashley Bischoff (blog at handcoding.com)]

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)

Comment 3

[Dave Miller [:justdave]]

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.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

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

Comment 5

[Dave Miller [:justdave]]

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)

Comment 6

[Ashley Bischoff (blog at handcoding.com)]

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.

Comment 7

[Dave Miller [:justdave]]

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.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

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

Comment 9

[Ashley Bischoff (blog at handcoding.com)]

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.

Comment 10

[Ashley Bischoff (blog at handcoding.com)]

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.

Comment 11

[Ashley Bischoff (blog at handcoding.com)]

Attachment: Event handling test page.

Comment 12

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 13

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 14

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 15

[Dave Miller [:justdave]]

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

Comment 16

[Jacob Steenhagen]

See also bug 76161 and bug 52885.

Comment 17

[Jesse Ruderman]

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.

Comment 18

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 19

[Jesse Ruderman]

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)">

Comment 20

[Joel Peshkin]

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.

Comment 21

[Max Kanat-Alexander]

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 [e-mail] 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.

Comment 22

[Frédéric Buclin]

Radio buttons are gone since Bugzilla 3.2.