Closed
Bug 696229
Opened 14 years ago
Closed 13 years ago
Text area : drag-and-drop to the start of a line : insertion point
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
mozilla15
People
(Reporter: nicolas.barbulesco, Assigned: ehsan.akhgari)
References
Details
(Keywords: regression)
Attachments
(1 file)
1.69 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
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
Blocks: 240933
Component: General → Editor
Keywords: regression
Product: Firefox → Core
QA Contact: general → editor
Version: unspecified → Trunk
![]() |
||
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•13 years ago
|
||
Assignee | ||
Updated•13 years ago
|
Whiteboard: [autoland-try:-b do -p all -u all -t none]
Updated•13 years ago
|
Whiteboard: [autoland-try:-b do -p all -u all -t none] → [autoland-in-queue]
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()?
Attachment #623239 -
Flags: review?(roc) → review+
Assignee | ||
Comment 4•13 years ago
|
||
(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?
Assignee | ||
Updated•13 years ago
|
Whiteboard: [autoland-in-queue]
> > 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•13 years ago
|
||
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
Assignee | ||
Comment 7•13 years ago
|
||
(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!
Assignee | ||
Comment 8•13 years ago
|
||
Target Milestone: --- → mozilla15
Comment 9•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 10•13 years ago
|
||
Hello,
Thank you. But now I encounter the same bug on Firefox 14.0.1, on Win Vista.
Nicolas
Status: RESOLVED → REOPENED
OS: Mac OS X → All
Hardware: x86_64 → All
Resolution: FIXED → ---
![]() |
||
Comment 11•13 years ago
|
||
This landed as you can ready easily per "Target Milestone" for Firefox 15 (currently in Beta http://www.mozilla.org/en-US/firefox/beta/).
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•11 years ago
|
||
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.
Assignee | ||
Comment 13•11 years ago
|
||
(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!
Reporter | ||
Comment 14•11 years ago
|
||
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.
Assignee | ||
Comment 15•11 years ago
|
||
(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!
You need to log in
before you can comment on or make changes to this bug.
Description
•