开发者

Javascript onChange arrow keys

开发者 https://www.devze.com 2023-03-17 05:55 出处:网络
Ok, so we all know that onChange is used to execute javascript code on a select statement when the option changes. However, if you change a select statement using the arrow keys, the onChange event is

Ok, so we all know that onChange is used to execute javascript code on a select statement when the option changes. However, if you change a select statement using the arrow keys, the onChange event is not called. Is there a way around this? Please help! I'm OCD I know.

--EDIT 1--

Just tested this in IE and arrow keys do work. Apparently it's just Chrome. ** Goes to check firefox

-- Edit 2 --

Tested in Firefox and realized just before an answer below talked about the onBlur action being required for the change. So the answer here is:

Internet Explorer re开发者_JAVA百科cognizes onChange events from the keyboard as well as clicking on them. Firefox and Chrome both require key events to be followed by blur event in order to call onChange.

Now normally, I don't like Internet Explorer, because it's a piece of garbage... But I think I... unfortunately, have to say they got that one right.

My understanding as to the reasoning for the blur event on chrome and firefox is to save resources, but I disagree with that. I feel it should follow the literal interpretation of the command onChange... Sigh... I suppose I'm probably wrong somehow, though.


I would suggest you to write the required code in Key Up event to capture the Key press and and also check for Key Code. Hope this helps


Scrolling through a select box is not considered a change. The change happens when you blur() the select and the new option value is applied to the select element.


Coming back to this, it appears that since the asking of this question, Chrome now fires onChange after key events. Firefox appears to still wait for onblur. http://jsfiddle.net/2aQBN/

$(document).ready(function() {
    $("#test").on("change", function() {
        console.log("Changed.");
    });
});

W3C Specification appears to suggest using an input event instead.

When the input event applies, any time the user causes the element's value to change, the user agent must queue a task to fire a simple event that bubbles named input at the input element.

However, no input event appears to fire in Chrome or Firefox for the select element. (Just input elements.)

Test demonstrating the current value vs the last onchange value.

http://jsfiddle.net/teynon/MpyHK/5/

Firefox will change the value onmouseover. The key change will change the value as well. However, the onchange hasn't fired. If the form submits while the user has the select menu open, the currently highlighted option is submitted.

From W3C:

If the multiple attribute is absent, and the element is not disabled, then the user agent should allow the user to pick an option element in its list of options that is itself not disabled. Upon this option element being picked (either through a click, or through unfocusing the element after changing its value, or through a menu command, or through any other mechanism), and before the relevant user interaction event is queued (e.g. before the click event), the user agent must set the selectedness of the picked option element to true and then queue a task to fire a simple event that bubbles named change at the select element, using the user interaction task source as the task source.

There is a LONG discussion at https://bugzilla.mozilla.org/show_bug.cgi?id=126379 about this with many people asking for the arrow keys to work. (And some defending the onchange approach.)

Some users have suggested that the W3C is flat out wrong in the specification for the select element's change event. Instead suggesting we propose changes to the specification for how we expect the select's onchange functionality to work.

The current functionality is clearly not intuitive to a large number of people based solely on the number of bug reports. (Mozilla has 40 marked as duplicates.)


This is a pretty dirty hack, but you can force the the change event to fire by doing this:

element.addEventListener('keyup', function(evt){
    evt.target.blur();
    evt.target.focus();
}, false);

So you'd register an event listener for change as well, and that function would get called when the user presses a key on the <select> via the code above.

You may want to scope this only to Firefox, but AFAIK you'd have to use UA sniffing for that so it's up to you if that's acceptable.

Source


I'm thinking about something like this (to not trigger event if value wasn't changed):

            select.keydown(function(){
                var _this = $(this);
                var _val = $(this).val();

                setTimeout(function(){    
                    if(_this.val() !== _val){
                        _this.trigger("change");
                    }
                }, 1);
            });


Here's a realization of this request. For brevity only showing the code. See https://github.com/ida/skriptz/blob/master/js/fields/select/selection_changed.js for long explanations in comments.

function addSelectionChangedListener(selectionEle, onChangeDoWithEle) {

  var selectedIndex = null

  function onChangeEvent(eve) {
    // If selection-change was caused of an option's click-event:
    if(eve.explicitOriginalTarget.tagName.toLowerCase() == 'option') {
      // We want to trigger passed event-handler:
      onChangeDoWithEle(eve.target)
    }
  }

  function onKeyEvent(eve) {

    // Key-event is keydown, remember current selectedIndex:
    if(eve.type == 'keydown') {
      selectedIndex = eve.target.selectedIndex
    }
    // Key-event is keyup, if selection changed, trigger passed handler:
    else if(selectedIndex != eve.target.selectedIndex) {
      onChangeDoWithEle(eve.target)
    }

  }

  selectionEle.onchange  = function(eve) onChangeEvent(eve)
  selectionEle.onkeydown = function(eve) onKeyEvent(eve)
  selectionEle.onkeyup   = function(eve) onKeyEvent(eve)

}
0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号