696229 - Text area : drag-and-drop to the start of a line : insertion point

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Nicolas Barbulesco]

I encounter a little glitch in text areas, like editing Wikipedia, in Firefox 6.0 on Mac OS X 10.6.8.

I create a new window. I go to http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&oldid=456569622 .
I select "{{Reference necessary|1=". I want to drag-and-drop this text to the beginning of the hard line. That is : just before "The measured light". So I try. When I am over the wanted destination, the insertion point must be at it too. But it is not ; it is at the preceding line. There is no way to have the insertion point just before "The measured light". However, I am confident and I drop my mouse. Happily, the text goes to the wanted destination, not to the insertion point.
I cancel.
Now, I want to drag-and-drop the text to the empty line above the paragraph. That is : just above "The measured light". So I try. When I am over the wanted destination, the insertion point must be at it too. But it is not ; it is at the preceding line, just after "RGB space.". However, I am confident and I drop my mouse. Happily, the text goes to the wanted destination, not to the insertion point.

See screen film :
http://screencast.com/t/PYxXVb2xLlMf

Thanks for fixing this little bug.

Nicolas

Comment 1

[Alice0775 White]

Regression window(cached m-c),
Works:
http://hg.mozilla.org/mozilla-central/rev/68033b993ed7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100913 Firefox/4.0b6pre ID:20100913165011
Fails:
http://hg.mozilla.org/mozilla-central/rev/ccaffbc6a970
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100913 Firefox/4.0b6pre ID:20100913162558
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=68033b993ed7&tochange=ccaffbc6a970

Triggered by:
c611f052ec92	Ehsan Akhgari — Bug 240933 - Part 1: Do not split multiline text into textframes separated by BR elements; r=roc a=dbaron

Comment 2

[(no longer active)]

Attachment: Patch (v1)

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 623239 [details] [diff] [review]
Patch (v1)

Review of attachment 623239 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/base/nsCaret.cpp
@@ +454,5 @@
> +static
> +nsFrameSelection::HINT GetHintForPosition(nsIDOMNode* aNode, PRInt32 aOffset)
> +{
> +  nsFrameSelection::HINT hint = nsFrameSelection::HINTLEFT;
> +  nsCOMPtr<nsIDOMCharacterData> node = do_QueryInterface(aNode);

How about QIing to nsIContent, calling GetText(), then CharAt()?

Comment 4

[(no longer active)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #3)
> Comment on attachment 623239 [details] [diff] [review]
> Patch (v1)
> 
> Review of attachment 623239 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: layout/base/nsCaret.cpp
> @@ +454,5 @@
> > +static
> > +nsFrameSelection::HINT GetHintForPosition(nsIDOMNode* aNode, PRInt32 aOffset)
> > +{
> > +  nsFrameSelection::HINT hint = nsFrameSelection::HINTLEFT;
> > +  nsCOMPtr<nsIDOMCharacterData> node = do_QueryInterface(aNode);
> 
> How about QIing to nsIContent, calling GetText(), then CharAt()?

I want to do this explicitly for text nodes.  Would that be the same?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> > How about QIing to nsIContent, calling GetText(), then CharAt()?
> 
> I want to do this explicitly for text nodes.  Would that be the same?

Calling GetText() would return non-null for exactly the nodes that implement nsIDOMCharacterData (which happens to include comments, CDATA and PIs).

Comment 6

[Mozilla RelEng Bot]

Autoland Patchset:
	Patches: 623239
	Branch: mozilla-central => try
	Destination: http://hg.mozilla.org/try/pushloghtml?changeset=ba8f89414e4b
Try run started, revision ba8f89414e4b. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=ba8f89414e4b

Comment 7

[(no longer active)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5)
> > > How about QIing to nsIContent, calling GetText(), then CharAt()?
> > 
> > I want to do this explicitly for text nodes.  Would that be the same?
> 
> Calling GetText() would return non-null for exactly the nodes that implement
> nsIDOMCharacterData (which happens to include comments, CDATA and PIs).

OK, then I'll do that!

Comment 8

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/793a4423093f

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/793a4423093f

Comment 10

[Nicolas Barbulesco]

Hello,

Thank you. But now I encounter the same bug on Firefox 14.0.1, on Win Vista.

Nicolas

Comment 11

[(mostly gone) XtC4UaLL [:xtc4uall]]

This landed as you can ready easily per "Target Milestone" for Firefox 15 (currently in Beta http://www.mozilla.org/en-US/firefox/beta/).

Comment 12

[Nicolas Barbulesco]

Thank you for your work Ehsan. The bug is partially fixed. But the bug still occurs when I drag-and-drop text on the last line of the text area when this last line is empty. I encounter the bug in Firefox 26 on Win 7. And I have encountered the bug on Mac too, in Firefox 25 I think.

Comment 13

[(no longer active)]

(In reply to comment #12)
> Thank you for your work Ehsan. The bug is partially fixed. But the bug still
> occurs when I drag-and-drop text on the last line of the text area when this
> last line is empty. I encounter the bug in Firefox 26 on Win 7. And I have
> encountered the bug on Mac too, in Firefox 25 I think.

Can you please file a new bug with exact details on how to reproduce it?  Thanks!

Comment 14

[Nicolas Barbulesco]

Ehsan, the bug is this one. 

To reproduce the remaining case :

1. Do the steps of the description. 
2. Select the word "typical". 
3. Try to drag-and-drop it in the last line, which is empty.

Comment 15

[(no longer active)]

(In reply to comment #14)
> Ehsan, the bug is this one. 
> 
> To reproduce the remaining case :
> 
> 1. Do the steps of the description. 
> 2. Select the word "typical". 
> 3. Try to drag-and-drop it in the last line, which is empty.

We have landed a patch inside this bug and therefore its status has been set to "RESOLVED FIXED".  Most Mozilla developers assume that there is nothing more to be done as part of these bugs, which is why I was asking you to file another bug so that it's clear that this part has not been fixed yet.  Thanks!