Open Bug 250622 Opened 20 years ago Updated 1 year ago
Caret shouldn't be shown during drag and drop unless text will be appended
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
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
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
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.
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)
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.
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
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
You need to log in before you can comment on or make changes to this bug.