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

NEW
Unassigned

Status

()

--
minor
15 years ago
7 years ago

People

(Reporter: gidsgoldberg, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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
(Reporter)

Comment 1

15 years ago
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.
Summary: Cursor shouldn't be shown when text is dragged to the Search or URL bars → Cursor shouldn't be shown during drag and drop unless text will be appended
Assignee: bugs → nobody
QA Contact: bugzilla → toolbars
(Reporter)

Comment 2

14 years ago
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!
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
(Reporter)

Comment 3

13 years ago
CC'ing in Gavin Sharp on this, as he's be doing wonders on Search as of late and this affects search. 
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.
(Reporter)

Comment 5

13 years ago
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)
(Reporter)

Updated

13 years ago
OS: All → Windows XP
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.
(Reporter)

Comment 7

13 years ago
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.
Summary: Cursor shouldn't be shown during drag and drop unless text will be appended → Caret shouldn't be shown during drag and drop unless text will be appended
Duplicate of this bug: 408014
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
Version: unspecified → Trunk

Updated

11 years ago
Blocks: 429992
Duplicate of this bug: 546378
Duplicate of this bug: 623369
OS: Windows XP → All
You need to log in before you can comment on or make changes to this bug.