Bug Tracker

#11638 closed bug (invalid)

Opened April 24, 2012 08:44PM UTC

Closed April 24, 2012 08:56PM UTC

Last modified April 24, 2012 09:12PM UTC

PreventDefault in keypress event cancels change event after multiple calls.

Reported by: admin@rushtheweb.com Owned by:
Priority: low Milestone: None
Component: event Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:
Description

Returning false or using preventDefault from a keypress handler for a textbox, will prevent a change event from triggering for the same textbox after multiple calls.

The steps to reproduce this bug are in the following jsFiddle: http://jsfiddle.net/portablesheep/hYmue/9/

You'll notice this example is using keypress to detect enter, and subsequently click a button. This example was chosen as it's a scenario I ran into at work.

Attachments (0)
Change History (2)

Changed April 24, 2012 08:56PM UTC by rwaldron comment:1

_comment0: I followed your instructions to the letter and I'm not sure how you didn't notice that your own documented instructions provide that insight to what is going on... \ \ > #1: Enter "1234" into the box, and press enter. -> Notice 'Submitted!' text. \ > #2: Press backspace, and then press tab. -> Notice 'Changed!' text. \ > #3: Place caret at end of the text, and press 4, followed by enter. -> Notice 'Submitted!' text. \ > #4: Press backspace, and then press tab. -> Notice 'Submitted!' text, when it should be 'Changed!' \ \ 1. The input is blurred as a result of tabbing away, the value is "123", a change event occurs \ 2. Restore focus by clicking back into the input \ 3. Change the value to "1234" \ 4. Delete "4", the value is "123" \ 5. The input is blurred as a result of tabbing away, the value is "123" \ \ ... Nothing has changed since the change event at #1, it is still "123" \ \ → 1335301019976712
_comment1: I followed your instructions to the letter and I'm not sure how you didn't notice that your own documented instructions provide the answer you need: \ \ > #1: Enter "1234" into the box, and press enter. -> Notice 'Submitted!' text. \ > #2: Press backspace, and then press tab. -> Notice 'Changed!' text. \ > #3: Place caret at end of the text, and press 4, followed by enter. -> Notice 'Submitted!' text. \ > #4: Press backspace, and then press tab. -> Notice 'Submitted!' text, when it should be 'Changed!' \ \ 1. The input is blurred as a result of tabbing away, the value is "123", a change event occurs \ 2. Restore focus by clicking back into the input \ 3. Change the value to "1234" \ 4. Delete "4", the value is "123" \ 5. The input is blurred as a result of tabbing away, the value is "123" \ \ ... Nothing has changed since the change event at #1, it is still "123" \ \ → 1335301051241785
component: unfiled → event
priority: undecided → low
resolution: → invalid
status: new → closed

I followed your instructions to the letter and I'm not sure how you didn't notice that your own documented instructions provide the answer you need:

1. Enter "1234" into the box, and press enter. -> Notice 'Submitted!' text. 2. Press backspace, and then press tab. -> Notice 'Changed!' text. 3. Place caret at end of the text, and press 4, followed by enter. -> Notice 'Submitted!' text. 4. Press backspace, and then press tab. -> Notice 'Submitted!' text, when it should be 'Changed!'

1. The input is blurred as a result of tabbing away, the value is "123", a change event occurs

2. Restore focus by clicking back into the input

3. Change the value to "1234"

4. Delete "4", the value is "123"

5. The input is blurred as a result of tabbing away, the value is "123"

... Nothing has changed since the change event at #1, it is still "123"

Changed April 24, 2012 09:12PM UTC by anonymous comment:2

I see what you're saying. I was under the impression that by pressing enter in this case with a different value than the original, that the change event would occur. I didn't think about the blur being the trigger, and blur not occurring in this scenario.