Closed Bug 128066 Opened 22 years ago Closed 13 years ago

DragNDrop: Drop into a textbox (input field) doesn't trigger "oninput" or "onchange" event

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Product:
Core
Component:
DOM: Copy & Paste and Drag & Drop
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: mcs, Unassigned)

References

Details

Using a build from Friday 2/22/2002.

If you drag and drop text in the "Link Location" field of the "Link Properties"
dialog, the OK button remains grayed out (disabled). You need to type something
in that field to activate it.

Steps to reproduce:

1) Create a new page to edit (Ctrl-Shift-N on Windows).

2) Open the "Link Properties" dialog (Ctrl-L on Windows).

3) Drag the URL from the URL bar in a Navigator window and drop it in the "Link
Location" field. The OK button does not activate.
Composer has an "oninput" event handler that responds to key input and pasting
just fine. This is a general bug in the drag and drop code -- dropping doesn't
trigger either an oninput or onchange event, so the enabling code doesn't get 
called. Changed summary for the more general problem.
I'm not sure who this should go to! Start with Drag and Drop component.
Assignee: cmanske → blaker
Component: Editor: Composer → XP Apps: Drag and Drop
QA Contact: sujay → claudius
Summary: link dialog: drag and drop does activate OK button → DragNDrop: Drop into a textbox (input field) doesn't trigger "oninput" or "onchange" event
Adding roger because of the NoteIt Sidebar Tab. Roger, can you add the noteIt
URL here and or check if this is the same bug you found? 

related to bug 129869?
*** Bug 203649 has been marked as a duplicate of this bug. ***
I have found a very related problem: if something is written or deleted within a
textbox (input field) using contextual menus (Cut, Delete, Paste), the OnChange
event is not fired either.

Should we create a new bug or change this one to extend the summary?
Blocks: 249173
No longer blocks: 249173
*** Bug 249173 has been marked as a duplicate of this bug. ***
*** Bug 261878 has been marked as a duplicate of this bug. ***
requesting OS be changed to 'All' since my bug was a dupe of this bug, and same
problem on XP with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041004 Firefox/0.10 and any branch before this one.
OS: Windows 2000 → All
Hardware: PC → All
An immediate testcase is with the find bar on firefox. If you drag and drop a
text selection onto the find bar, the next/prev buttons still remain disabled.

I do this all the time with Google's Cached Pages. I search for a sentence on
Google and then click on the "Cached" link. Then to find the first occurence of
that sentence in the cached page, I open the find bar (Edit -> Find..), then
drag and drop the sentence from the top of page to the find bar. Then I go to
the find bar and press "space" then "backspace" (to dispatch the "oninput"
event) and the search begins.

Also if you type something in the find bar (e.g., "goo"), and then you drag and
drop some text to the find bar (e.g., "gle") and click "Find Next" the new text
("google") is not searched but the old one ("go") is still searched, even though
the textbox says "google".
*** Bug 284029 has been marked as a duplicate of this bug. ***
*** Bug 308218 has been marked as a duplicate of this bug. ***
The Find bar now works around this bug (see bug 296827).
*** Bug 170540 has been marked as a duplicate of this bug. ***
brade, so it turns out that the problem here is really simple: the dropped-on textbox doesn't have focus, so it never generates input events.
Assignee: firefox → nobody
QA Contact: claudius
Depends on: 280635
*** Bug 326806 has been marked as a duplicate of this bug. ***
Blocks: 326792
Blocks: 405277
This is in response to comment #14. The problem seems not really to be based on the text box not having focus. You can reproduce it when the box has focus as well.
Load a page like so,
<html><body><form><input onchange="alert('changed') type="text"" /></form></body></html>

Enter "some text to move" in the text input. Click away from the box. "changed" alert will pop up correctly when the box loses focus. Now, highlight the word "text" with your mouse, click on the word, and drag it to a different part of the box, so that the original phrase becomes garbled. The cursor is still in the box, and would receive text if you started typing. But instead, click away from the box. No change event is triggered when the box loses focus.

I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090120 Minefield/3.2a1pre.
Sorry, I guess the explanation is that a text control loses focus temporarily even if the drag occurs within that control. So 
1 you start to drag, 
2 the control loses focus, 
3 you deposit the text without the control having focus, hence no onchange event
4 the control regains focus, but starting with the new text.
So it is a focus issue.
Wow! This bug was filed in 2002 (7, yes! 7 years ago). It's still not resolved in firefox 3.0.7.
7 years... and I still get mailed about this =D
Goodbye fuckers (with all due respect, seriously)!
QA Contact: drag-drop
Depends on: 522787
can somebody retest, on attachment 206034 [details] I see DragNDrop firing input event.
it use .addEventListener('input', onInput, true); not the HTML attribute oninput
Drag and drop do trigger an input event. However, it does not run a change event per spec: you have to blur the element and the element isn't focused by a drag and drop (no browser do that AFAIK and I haven't see a native UI doing that too).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Verified on comm-1.9.2, related Calendar bug is no longer reproducible.
Status: RESOLVED → VERIFIED
(In reply to Mounir Lamouri (:mounir) from comment #23)
> Drag and drop do trigger an input event. However, it does not run a change
> event per spec: you have to blur the element and the element isn't focused
> by a drag and drop (no browser do that AFAIK and I haven't see a native UI
> doing that too).

Other browsers (even IE) put the focus the input field where the text has been dropped, so when you click somewhere else on the page, the onchange event is fired.
Please try the test case provided in one of the duplicates :
https://bug435137.bugzilla.mozilla.org/attachment.cgi?id=347237
The development of other browsers - and so the 'common sense' seems to have changed, so I reopen this ticket, doing a followup on comment #23.

Testing actual browsers (Firefox 36, Internet Explorer 11, Chrome 41, Opera 28) with the test page from comment #26 shows up this result: Firefox is the only one, that remains on that behaviour. All others fire a change event on a drop. And by the way, the put the focus onto the input field, also. So their behaviour is consistent to Your definition (change only on lost focus).

And - to be honest - that behaviour is more or less that, what I would prefer to call "common to the user".

So, finally, I would be happy, if this could be revised and hopefully "adjusted".
You need to log in before you can comment on or make changes to this bug.