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
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
Created attachment 623239 [details] [diff] [review] Patch (v1)
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()?
(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?
> > 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).
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
(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!
https://hg.mozilla.org/integration/mozilla-inbound/rev/793a4423093f
https://hg.mozilla.org/mozilla-central/rev/793a4423093f
Hello, Thank you. But now I encounter the same bug on Firefox 14.0.1, on Win Vista. Nicolas
This landed as you can ready easily per "Target Milestone" for Firefox 15 (currently in Beta http://www.mozilla.org/en-US/firefox/beta/).
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.
(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!
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.
(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!
or
