Created attachment 8657056 [details] Testcase User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150826023504 Steps to reproduce: Having an <input type="text"> or <textarea> with an onchange-Attribut defined. Testing (a) Input by single strokes on keypad (b) Input by clipboard (copy and paste) (c) Input by drag and drop (mouse movement) Actual results: On keystrokes onchange and oninput (in that order) are fired each time, on copy and paste onchange and oninput are fired and on drag and drop only oninput is fired. Testing with Firefox 40.0.3 Expected results: On drag and drop also onchange is expected to be fired. This is common behaviour on "the other major browsers" (Internet Explorer 11 and Edge, Google Chrome 45 resp. Opera 31.0) The different flow is some kind annoying (building browser switches...) and even unexpected from (my) logic - the field content "has changed", so it would be logic to me to have onChanged be fired. But this is just human thinking :-) This bug is connected to bug 128066 https://bugzilla.mozilla.org/show_bug.cgi?id=128066 Reason might be the handling of focus as mentioned in comment 26 of that bug. I attached an prepared html for this.
Component: Untriaged → Drag and Drop
Product: Firefox → Core
Confirmed in Firefox 43.0a2 on OS X El Capitan.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed in Firefox 46.0.1 on Windows 7.
Version: 40 Branch → 46 Branch
OS: Unspecified → All
Hardware: Unspecified → All
Version: 46 Branch → 47 Branch
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-ie, parity-safari
You need to log in before you can comment on or make changes to this bug.