250622 - Caret shouldn't be shown during drag and drop unless text will be appended

Status: NEW

(Firefox :: Toolbars and Customization, defect)

Description

[Gids Goldberg]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

Following the fixing of Bug 176675 when text is dragged to the URL or search
bars it is automatically loaded. However, when content is dragged over these
areas a keyboard cursor appears suggesting the text will be appended to these
areas. A better solution would be either to show no cursor (as in IE,) or to
highlight any exisitng contents to suggest it will be overwritten.

Reproducible: Always
Steps to Reproduce:
Drag and Drop text onto the search bar


Actual Results:  
A cursor appears in the search bar suggesting the text will be appended

Expected Results:  
Either no cursor should be shown or the existing text should be highlighted

Comment 1

[Gids Goldberg]

I'm changing the summary of this bug to cover all the cases where the cursor is
shown but the text dragged is not appended to the field. This includes text
dragged to the address bar or where links are dragged to the address bar.

Comment 2

[Gids Goldberg]

Marking NEW since I think this bug is valid and I don't want it to be
Auto-Resolved. Feel free to mark otherwise if you know better!

Comment 3

[Gids Goldberg]

CC'ing in Gavin Sharp on this, as he's be doing wonders on Search as of late and this affects search. 

Comment 4

[:Gavin Sharp [email: [e-mail]]]

I'm not sure I agree. The cursor I see doesn't say "text will be appended", it says "you're dragging something, and you can drop it here". However, if I hold control while dragging, I see the same cursor, but with a "+" in it, which could potentially be confusing, I suppose. I don't think there's much that can be done about that. canDrop can return false if the Ctrl key is depressed. That would have to be done per-drag handler, so it doesn't really solve the general problem.

Comment 5

[Gids Goldberg]

Gavin, I don't think the Windows HIG is with you on this one:

"Display the pointer appropriate to the context of the destination, usually the pointer used for inserting objects. For example, when the user drags an object into text <<where the object will be inserted between characters>>, display the usual text editing pointer (sometimes called the I-beam pointer)." (emphasis mine)

Comment 6

[:Gavin Sharp [email: [e-mail]]]

If the text will be added "between characters", we should show the I-beam. Except that we don't add it between characters, we replace it entirely.

I think you're confusing the cursor with the caret. We probably should not show the caret... I hadn't noticed that we did, when I was testing before.

Comment 7

[Gids Goldberg]

Good call on this one, I meant what you refer to as the caret. It seems 'cursor' is used for both the 'i-beam' and for the 'mouse cursor,' which I guess caused the confusion.

Comment 9

[Samuel Sidler (old account; do not CC)]

I also reproduced this using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007121107 Minefield/3.0b2pre

Comment 12

[Release mgmt bot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 3 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 13

[Release mgmt bot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.