1273655 - Link in paragraph gets extended/repeated onto new line when hitting Enter

Status: RESOLVED DUPLICATE of bug 1422234

(Core :: DOM: Editor, defect, P3)

Description

[Jorg K (CEST = GMT+2)]

Attachment: Testpage showing the bug

Link in paragraph gets extended/repeated onto new line when hitting enter.

Try the attached test case. It says more than 1000 words.

Maybe related to bug 1250805.

Comment 2

[Matt]

It is not just pressing enter,  continuing typing after inserting a link continues the link as well.  I would expect the link to end with the existing text,  but it does not.

Comment 3

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Only happens because of the <p>.  Without the <p>, it doesn't follow the newline.  (Sigh.  <br> for newline is a bad choice.)

Chrome and Edge both match the behavior suggested in comment 2.  For bold, clicking at the end of the line and typing will insert bold text.  But for a link, it doesn't.  We should probably change to match this behavior.

Comment 5

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I did some testing with the following text in a contenteditable div:

  foo<a href=a>bar</a>baz<br>foo<b>bar</b>baz

I tried to position the cursor at the start and end of the word "bar" on both lines, then typed "x" to see if the letter went inside or outside the tag.  In Blink, Edge, and LibreOffice, no matter how I try to position the cursor (keyboard and mouse from either side), the "x" always goes outside the link, and for the <b>, it goes outside at the beginning and inside at the end.  This seems reasonable.

In Firefox, for both link and bold, it depends on the side you come from.  If you navigate with the keyboard from inside the tag, it will be inside.  If from outside, it will be outside.  If you click on the outer edge of "bar", it will be inside.  If from the end of "foo" or beginning of "baz", it will be outside.  I can see the logic in this, but in practice it doesn't match other implementations, and the mouse part especially is confusing (it depends on the exact pixel you click on).

So I think we should change to match other UAs here.  I don't know offhand where the relevant code lives, though.  I suspect it will have to be made smarter.

Comment 6

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Masayuki, do you know where the code is that decides where to place the cursor when you click somewhere, navigate with arrow keys, etc.?  Or know who would know?

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Although, I'm not so familiar with the implementation:

nsFrameSelection::MoveCaret() (keyboard)
> https://dxr.mozilla.org/mozilla-central/rev/24763f58772d45279a935790f732d80851924b46/layout/generic/nsSelection.cpp#951,1055-1056,1063-1065,1095,1154-1155

nsFrame::HandlePress(), nsFrameSelection::HandleClick() (mouse)
> https://dxr.mozilla.org/mozilla-central/rev/24763f58772d45279a935790f732d80851924b46/layout/generic/nsFrame.cpp#3197,3258,3281-3285,3298,3307-3308,3400-3402

Comment 8

[Jorg K (CEST = GMT+2)]

I worked in that code a bit, see changes to layout/generic/nsFrame.cpp in
https://hg.mozilla.org/mozilla-central/rev/bf414f68291c

Comment 9

[Jorg K (CEST = GMT+2)]

Aryeh, when you return at the end of October, do you think there is a chance to get this fixed in mozilla52 before the next branch date, 7th of Nov. 2016. I know, it's a bad question since some bugs take longer and then miss the branch date by a few hours.

Comment 10

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I think I'm not going to work on bugs like this anymore unless they affect major real-world sites.  Real-world editors on sites normally handle user input themselves, so this type of change is of extremely little benefit to Firefox users and is very prone to breaking things.

Comment 12

[veganaiZe]

Simple fix:
===========

          Format --> Discontinue Link (Ctrl+Shift+K)


Ref:  https://bugzilla.mozilla.org/show_bug.cgi?id=588571#c4

Comment 16

[Thomas D. (:thomas8)]

Testcase of attachment 8753532 [details] is now working correctly (link discontinued when pressing Enter after the link).
This was fixed in Bug 1422234 - Pressing Enter after an anchor link causes the content in new line to associate with the link.

Unfortunately, for most Thunderbird bugs which were generously duped here, the problem remains for typing anything else but Enter after a trailing link, which is seriously annoying because it makes any such link "sticky" with no easy way to discontinue it (Ctrl+Shift+K or other workarounds aren't easy). The remaining case (and the key problem for Thunderbird) is Bug 1357365:

Bug 1357365 - Can't exit links in contenteditable elements

I will reshuffle duplicates accordingly.

(In reply to Masayuki Nakano [:masayuki] from Bug 1357365 comment #2)

After landing bug 1422234, pressing Enter at end of link stops creating
another <a> element in new paragraph. However, we still don't have a way to
put caret outside the <a> element.

(In reply to Masayuki Nakano [:masayuki] from Bug 1357365 comment #3)

After landing bug 1496320, if caret is moved from outside of <a href>, typing new character at edge of the element is treated as typing outside it. I guess that the remaining issue is, the case when there is no content before or after <a href> in the block or line.