Last Comment Bug 696229 - Text area : drag-and-drop to the start of a line : insertion point
: Text area : drag-and-drop to the start of a line : insertion point
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: All All
: -- minor with 1 vote (vote)
: mozilla15
Assigned To: :Ehsan Akhgari (busy, don't ask for review please)
:
Mentors:
Depends on:
Blocks: 240933
  Show dependency treegraph
 
Reported: 2011-10-20 15:00 PDT by Nicolas Barbulesco
Modified: 2014-01-21 14:05 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (v1) (1.69 KB, patch)
2012-05-11 11:51 PDT, :Ehsan Akhgari (busy, don't ask for review please)
roc: review+
Details | Diff | Review

Description Nicolas Barbulesco 2011-10-20 15:00:59 PDT
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 2011-10-20 16:02:10 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-05-11 11:51:22 PDT
Created attachment 623239 [details] [diff] [review]
Patch (v1)
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-05-11 15:47:10 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-05-11 15:50:16 PDT
(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) (Exited; email my personal email if necessary) 2012-05-11 16:08:21 PDT
> > 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 2012-05-11 16:11:33 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2012-05-11 16:18:24 PDT
(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 :Ehsan Akhgari (busy, don't ask for review please) 2012-05-14 16:35:15 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/793a4423093f
Comment 9 Ed Morley [:emorley] 2012-05-15 06:33:03 PDT
https://hg.mozilla.org/mozilla-central/rev/793a4423093f
Comment 10 Nicolas Barbulesco 2012-08-26 05:47:25 PDT
Hello,

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

Nicolas
Comment 11 XtC4UaLL [:xtc4uall] 2012-08-26 06:06:38 PDT
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 2014-01-16 05:15:20 PST
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 :Ehsan Akhgari (busy, don't ask for review please) 2014-01-20 18:47:24 PST
(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 2014-01-21 03:27:54 PST
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 :Ehsan Akhgari (busy, don't ask for review please) 2014-01-21 14:05:36 PST
(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!

Note You need to log in before you can comment on or make changes to this bug.