501152 - change event not fired when a a form field is modified by a drag and drop

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Philippe Metzger]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11

The onchange JS event is not fired when the content of a form text field is modified by using a drag and drop opération.

Reproducible: Always

Steps to Reproduce:
1.create a page with a form with a text field and some text outside the form.
2.add a onchange handler on the text field
3.select some text on the page
4.put some text in the text field using a drag and drop
Actual Results:  
the onchange event is not fired when you the field loose the focus

Expected Results:  
Firefox should have fired the onchange event

I have made test on LINUX/OS X/WINDOWS for firefox 3.0.X and on Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4pre) Gecko/20090401 Ubuntu/9.04 (jaunty) Shiretoko/3.5b4pre 
The behaviour is the same, the event is not fired.

Comment 1

[Garrett Smith]

I can confirm that dragging text to an input does not cause onchange to fire.

I believe this is because the input does not receive focus. 

This seems like the correct behavior, per spec.
http://www.w3.org/TR/html4/interact/scripts.html#adef-onchange

Comment 2

[George Carstoiu]

Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110809 Firefox/8.0a1

Are you still able to see this on the latest trunk?

Thanks!

Comment 4

[Garrett Smith]

(In reply to Garrett Smith from comment #1)
> I can confirm that dragging text to an input does not cause onchange to fire.
> 
> I believe this is because the input does not receive focus. 
> 
> This seems like the correct behavior, per spec.
> http://www.w3.org/TR/html4/interact/scripts.html#adef-onchange
That is correct, per HTML 4, which states:

|The onchange event occurs when a control loses the 
| input focus and its value has been modified since 
| gaining focus.

HTML5 redefined the "change" event conditions to:

| When the change event applies, if the element does 
| not have an activation behavior defined but uses a 
| user interface that involves an explicit commit 
| action, then any time the user commits a change to 
| the element's value or list of selected files, the 
| user agent must queue a task to fire a simple event 
| that bubbles named change at the input element.
http://www.whatwg.org/specs/web-apps/current-work/#event-input-change

I don't see where "explicit commit action" is defined (your guess is as good as mine). I surmise that a drop action would be an explicit "commit" action. 

HTML5 mentions the "input" event. AFAICT, it mentions, but does not actually define "when the input event applies". Instead, HTML5 describes what should happen under that case and when the user causes the input element's value to change. 

http://www.whatwg.org/specs/web-apps/current-work/#event-input-input

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

I'm unsure what they wanted to say. Your guess is as good as mine.

Comment 5

[Mounir Lamouri (:mounir)]

Opera and Chrome seems to focus the element after a drag and drop operation so they fire the focus event as soon as the element is blurred. Though, it doesn't seem to follow my platform conventions.

I don't think we should focus the element if the platform doesn't do that but I think firing a change event might be what developers would expect here. Should we just do that and ask a change in the specifications?

Comment 6

[Neil Deakin]

It should only fire the change event once the element is blurred. If the element wasn't focused anyway, it probably should not fire it at all.

Comment 7

[(no longer active)]

(In reply to Neil Deakin from comment #6)
> It should only fire the change event once the element is blurred. If the
> element wasn't focused anyway, it probably should not fire it at all.

I disagree.  The change event doesn't have anything to do with the element being blurred.  We just fire it that way for focused elements as a signal when the user has finished changing an element.  For drag and drop, the change event should fire when the drop happens, unless we decide to focus the element after something gets dropped into it.

Comment 8

[Neil Deakin]

(In reply to Ehsan Akhgari [:ehsan] from comment #7)
> (In reply to Neil Deakin from comment #6)
> > It should only fire the change event once the element is blurred. If the
> > element wasn't focused anyway, it probably should not fire it at all.
> 
> I disagree.  The change event doesn't have anything to do with the element
> being blurred.

OK, well it was at one point defined in the events spec to only fire on blur, but it's possible some new spec variation may have changed that.

Generally, I use the input event to listen to specific changes regardless of focus, as that works with key entry, pasting and dropping.

Comment 9

[Garrett Smith]

(In reply to Ehsan Akhgari [:ehsan] from comment #7)
> (In reply to Neil Deakin from comment #6)
> > It should only fire the change event once the element is blurred. If the
> > element wasn't focused anyway, it probably should not fire it at all.
> 
> I disagree.  The change event doesn't have anything to do with the element
> being blurred.  

Depends which spec you consult. See the HTML 4 quote in comment 4.

We just fire it that way for focused elements as a signal
> when the user has finished changing an element.  For drag and drop, the
> change event should fire when the drop happens, unless we decide to focus
> the element after something gets dropped into it.
First ask on WHATWG mailing list if "dropping" constitutes an "explicit commit action" in HTML5. 

This bug is valid only if the answer is "yes". I bet it is, but it needs to be confirmed before committing patches.