Drag and Drop in input controls is broken

VERIFIED FIXED in mozilla1.9.1b2

Status

()

P1
blocker
VERIFIED FIXED
10 years ago
6 years ago

People

(Reporter: robert.stopp, Assigned: mano)

Tracking

({regression, verified1.9.1})

Trunk
mozilla1.9.1b2
regression, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: 

Drag and drop in input controls in a current nightly results in unloading the current page and trying to resolve the the dropped fragment against DNS and search engines.
It seems that every input control is handled like the adressbar.
The behaviour exist max. two weeks, before this change drag and drop was complete broken.

Reproducible: Always
(Reporter)

Updated

10 years ago
Severity: major → blocker
Version: unspecified → Trunk

Updated

10 years ago
Blocks: 459334

Updated

10 years ago
Summary: Drand and Drop in input controls is broken → Drag and Drop in input controls is broken

Comment 1

10 years ago
Confirming on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081007 Minefield/3.1b2pre ID:20081007173602.
Status: UNCONFIRMED → NEW
Component: Location Bar and Autocomplete → Drag and Drop
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: location.bar → drag-drop

Updated

10 years ago
Flags: blocking1.9.1?
OS: Windows XP → All

Updated

10 years ago
Duplicate of this bug: 459355

Comment 3

10 years ago
Works: http://hg.mozilla.org/mozilla-central/rev/1630d60e624e
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081006
Minefield/3.1b1pre

Broken: http://hg.mozilla.org/mozilla-central/rev/55366228f456
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081007
Minefield/3.1b1pre
Seems most likely to be bug 458070 or bug 455311, does it not?
There's no way bug 455311 causes this, especially not on Linux: it's a Windows-only change.  Bug 458070 certainly could, though!
Blocks: 458070

Comment 6

10 years ago
I just verified that backing out the patch for bug 458070 fixes this bug as well as bug 459334, so Boris is right.
(Reporter)

Comment 7

10 years ago
(In reply to comment #6)
> I just verified that backing out the patch for bug 458070 fixes this bug as
> well as bug 459334, so Boris is right.

Elmar: Is it possible to drag a selection from inside an textarea/input?


By working on this: Imo it would be better if a selection in the adressbar is dragged to another place in the adressbar (even with Ctrl-key pressed), the original value + new location of the dropped fragment would be the result.

Comment 8

10 years ago
(In reply to comment #7)
> Elmar: Is it possible to drag a selection from inside an textarea/input?

Yes.

> By working on this: Imo it would be better if a selection in the adressbar is
> dragged to another place in the adressbar (even with Ctrl-key pressed), the
> original value + new location of the dropped fragment would be the result.

Feel free to file an enhancement request for this (if there isn't already one).
Created attachment 342734 [details] [diff] [review]
Remove the usage of the dragdrop event and nsIDOMDragListener interface

I'm handling the places code in other bugs.
Assignee: nobody → mano
Status: NEW → ASSIGNED
Attachment #342734 - Flags: superreview?(jonas)
Attachment #342734 - Flags: review?(Olli.Pettay)
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b2
Attachment #342734 - Flags: review?(Olli.Pettay) → review+
Comment on attachment 342734 [details] [diff] [review]
Remove the usage of the dragdrop event and nsIDOMDragListener interface

> nsContentAreaDragDrop::HookupTo(nsIDOMEventTarget *inAttachPoint,
>                                 nsIWebNavigation* inNavigator)
> {
>+  printf("\n\n\n\n\nIn HookupTo %d %d\n\n\n", inAttachPoint != 0, inNavigator != 0);
Remove this.

> NS_IMETHODIMP
> nsContentAreaDragDrop::HandleEvent(nsIDOMEvent *event)
> {
Make sure that event is really a drag event.
So you need to QI to nsIDOMDragEvent

>+  nsresult DragOver(nsIDOMEvent* aMouseEvent);
>+  nsresult Drop(nsIDOMEvent* aMouseEvent);
...then you could change these to take nsIDOMDragEvent as a parameter, if needed.

> nsTextEditorDragListener::HandleEvent(nsIDOMEvent* aEvent)
> {
Same here, you need to check that aEvent is nsIDOMDragEvent

> nsresult
> nsPluginInstanceOwner::HandleEvent(nsIDOMEvent* aEvent)
And also here. And actually, because all the drag events
get handled the same way, you don't need to compare eventType if
aEvent implements nsIDOMDragEvent

>-  gToolbox.addEventListener("draggesture", onToolbarDragGesture, false);
>+  gToolbox.addEventListener("dragstart", onToolbarDragStart, false);
>   gToolbox.addEventListener("dragover", onToolbarDragOver, false);
>-  gToolbox.addEventListener("dragexit", onToolbarDragExit, false);
>-  gToolbox.addEventListener("dragdrop", onToolbarDragDrop, false);
>+  gToolbox.addEventListener("dragleave", onToolbarDragLeave, false);
>+  gToolbox.addEventListener("drop", onToolbarDrop, false);
Here you add listener for dragstart

> function removeToolboxListeners()
> {
>-  gToolbox.removeEventListener("draggesture", onToolbarDragGesture, false);
>+  gToolbox.removeEventListener("draggesture", onToolbarDragStart, false);
>   gToolbox.removeEventListener("dragover", onToolbarDragOver, false);
>-  gToolbox.removeEventListener("dragexit", onToolbarDragExit, false);
>-  gToolbox.removeEventListener("dragdrop", onToolbarDragDrop, false);
>+  gToolbox.removeEventListener("dragexit", onToolbarDragLeave, false);
>+  gToolbox.removeEventListener("dragdrop", onToolbarDrop, false);
...but don't remove it here.

Those fixed and mochitest or browser tests added, r=me

Comment 11

10 years ago
(In reply to comment #10)
> Here you add listener for dragstart
> [...]
> ...but don't remove it here.

Same for "dragleave" and "drop", BTW.
Created attachment 343057 [details] [diff] [review]
patch
Attachment #342734 - Attachment is obsolete: true
Attachment #343057 - Flags: superreview?
Attachment #342734 - Flags: superreview?(jonas)
Attachment #343057 - Flags: superreview? → superreview?(jonas)
Er... if you feel the need to wrap aURI, why not aWhat and aValue?
Sorry, the changes to feedwriter.js belong to bug 360529.
Attachment #343057 - Flags: superreview?(jonas) → superreview+
Comment on attachment 343057 [details] [diff] [review]
patch

Yay!! We should get rid of more interfaces like this. (AddEventListenerByIID needs to die IMHO)
I'm going to land this ASAP, but without tests. I couldn't figure out how to test this in mochitest. I tried to do what test_dragstart does (note it doesn't test full d&d either). Simply dispatching mousedown+mousemove on the drag-able element and mousemove on the target element didn't generate dragover events. I'm pretty sure I'm also running here into a 100% reproducible case for bug 455871 since D&D seems to get completely broken when running this test, don't ask me how.
Duplicate of this bug: 460559

Updated

10 years ago
Duplicate of this bug: 460449

Comment 20

10 years ago
I reported Bug 460559, then I found it is marked as a duplicate of this bug. So
I post another case which probably belongs here too.

Environment:
Firefox 3.1b1, Windows xp

Summary:
Drag and drop behavior is different. It depends on the selecting method .

Steps:
1. Get a page with a textarea, e.g. Bug 459323 (just this page)
2a. 
  2a1. Hold left button and move the cursor through to select some text
  2a2. Drop the selection in the textarea, e.g. Additional Comments box in the
bottom of the page
  Result of 2a: The selection is copied to the drop point

2b. 
  2b1. Double/triple click to select some text
  2b2. Drop the selection in the textarea
  Result of 2b: The current page is refreshed to a new URL

Other infomation:
In the case 2a and 2b, it doesn't matter whether the selected text is from
outside or inside the textarea.
I checked this in yesterday.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 22

10 years ago
The problem with the unloading page is fixed but now there is no insert caret while dragging - this happens on all drag and drop operations and even in designmode, drag and drop from inside an input control is not possible on Windows.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 23

10 years ago
I had the problem with the invisible insert caret some time before. This was caused by the "drag" - event on a designmode document.
Marking FIXED again, don't reopen this bug unless you can tell for sure that the describe behavior regressed from the same patch. If the caret issue is a result of this bug, file a bug blocking it, or otherwise just file a bug.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Comment 25

10 years ago
This bug is not really fixed -- only partially.

I can drag-and-drop into a text filed, but I can neither: (1) drag-and-drop within a text area nor (2) drag-and-drop from a text area.
(Reporter)

Comment 26

10 years ago
(In reply to comment #24)
> Marking FIXED again, don't reopen this bug unless you can tell for sure that
> the describe behavior regressed from the same patch. If the caret issue is a
> result of this bug, file a bug blocking it, or otherwise just file a bug.

Can you drag a selection from inside an input control?

Comment 27

10 years ago
(In reply to comment #25)
> This bug is not really fixed -- only partially.

Yes, I see this as well. I also noticed what Robert mentioned: the caret is
missing while dragging over a text area or input field.

I just tested the last tinderbox build from before the checkin of this patch
and the first one containing this patch and can confirm that all three problems
were caused by this checkin.

Updated

10 years ago
Depends on: 460595

Updated

10 years ago
Depends on: 460596

Comment 28

10 years ago
Filed bug 460595 and bug 460596 on the regressions mentioned by IU and Robert.
I checked in a fix for some typos i did, which probably caused this bustage: http://hg.mozilla.org/mozilla-central/rev/2090e8775575

Let me know if things are still buggy in the next build.

Comment 30

10 years ago
This fixes the caret problems for me, but dragging a text selection from an input control still does not work in a current build.
Flags: in-litmus?
Hardware: PC → All

Updated

10 years ago
Depends on: 460903

Updated

10 years ago
No longer depends on: 460903
Flags: blocking1.9.1? → blocking1.9.1+

(In reply to comment #25)
> This bug is not really fixed -- only partially.
> 
> I can drag-and-drop into a text filed, but I can neither: (1) drag-and-drop
> within a text area nor (2) drag-and-drop from a text area.

Using STR here, verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
en-US; rv:1.9.2a1pre) Gecko/20090122 Minefield/3.2a1pre 
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre)
Gecko/20090122 Shiretoko/3.1b3pre
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1

Comment 33

10 years ago
Is this fixed in branch? From comment #32 it looks as it is, but testing with current branch I can drag this same text to the search box just sitting below and it doesn't get moved, just copied. So it's not fixed, unless I'm misunderstanding what the bug is for.
Jose, this bug is described in comment 0.  If you drag and drop and the page doesn't unload, this bug is fixed.
You need to log in before you can comment on or make changes to this bug.