Issue metadata
Sign in to add a comment
|
change event firing differently in 56.0.2924.87
Reported by
kevinzu...@gmail.com,
Feb 14 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Bind change event to input element 2. Add text to input element from (1) 3. Switch to new element and lose focus of element from (1) via tab or clicking What is the expected behavior? Until updating to Chrome 56.0.2924.87 the expected behaviour was that the change event would NOT fire for the steps listed. What went wrong? The change event is now firing for these steps Did this work before? Yes 56.0.2924.79 Chrome version: 56.0.2924.87 Channel: stable OS Version: Ubuntu 16.04 Flash Version: Shockwave Flash 24.0 r0 The latest version working was tested on iOS. I am not sure if it works for versions between 56.0.2924.79 and 56.0.2924.87.
,
Feb 14 2017
The change event should fire on step 3 according to specs on MDN [1]: >When the element loses focus after its value was changed I've tried various versions of Chrome and there is no difference. Can you attach a test case html which exposes the difference in an obvious way? [1]: https://developer.mozilla.org/en-US/docs/Web/Events/change
,
Feb 14 2017
@kevinzurek: Could you please provide us any sample html file to triage the issue from test team end. Thanks,
,
Feb 16 2017
Hi all, It is correct that the behavior being experienced now is correct per MDN standards. We changed our code to use the "input" event instead of the "change" event and this fixed the issue.
,
Feb 20 2017
Thanks for the update. Closing this issue as per comment #4. @kevinzurek:Please feel free to raise a new issue if you face any issue on chrome further. Thanks, |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Feb 14 2017