75035 - if paste flat text after deleting final 1+ characters of a link, flat text is pasted into link text instead of after it

Status: RESOLVED DUPLICATE of bug 1357365

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

Description

[ekrock's old account (dead)]

Using M8 on WinME.

To repro:
1) launch composer
2) type some text & hit return
3) click on bullet list
4) insert a link
5) now, copy the text & past it after the link

Expected: flat text pasted as flat text (as user expects, and as Nav4 Composer
would do)

Actual: text becomes part of the link--absolutely not what the user wants or expects

May be related to bug 55079, Can't Discontinue a link inside a list (in context
menu).

Comment 1

[ekrock's old account (dead)]

Marking 4xp. Nominating nsbeta1,mozilla1.0. 

Comment 2

[rubydoo123]

you would have to exit out of the link element first, see the comments in bug 
55079.

Comment 3

[Eric Krock]

OK, the procedure to reproduce is slightly more involved: turns out you have to
delete backwards the last 1+ characters of the link. If you then paste in that
state, the text is pasted into the link instead of as flat text. 

To repro:
1) launch composer
2) type some text, select it, copy it, & hit return
3) click on bullet list
4) insert a link
5) delete the last 1+ characters of the link
5) now, paste

One *could* view this as either a bug or a feature.

BUG VIEWPOINT: This is incompatible with the behavior of Nav4 Composer, possibly
with other authoring programs (anyone know?), and with the user expectation that
copy-and-paste will not alter what's being copied & pasted.

FEATURE VIEWPOINT: This for the first time means that with Composer, you can
paste text into the text of a link instead of having to manually enter it. This
is a nice enhancement! Plus, if you Discontinue Link after the deletion, you
should then be able to paste the flat text as text.

Changing Summary from "can't paste flat text after a link which is at the end of
a bullet" to "if paste flat text after deleting final 1+ characters of a link,
flat text is pasted into link text instead of after it."

Withdrawing mozilla1.0 and nsbeta1 nominations; leaving 4xp. You may well choose
to resolve this 4xp behavior issue with WONTFIX since Discontinue Link provides
a straightforward solution. The key to enabling users not to get hung up on this
is to raise the visibility of Discontinue Link in the UI (by surfacing in the
context menu perhaps? see bug 55079) so they're aware of its presence. Nav4
Composer lacked this so users (like me!) won't know to look for it and may
overlook its presence.

ALTERNATIVE POSSIBLE SOLUTION TO ENABLE PASTING OF TEXT INTO LINK TEXT: Could we
make the text of links editable (and pasteable) within the Link Properties
dialog box? Currently, only the link target URL is editable there. That would
obviously be a post-nsbeta1 timeframe enhancement request.

Nice job on Discontinue Link folks--I'm happy to be using M8 Composer for my
HTML editing!

Comment 4

[rubydoo123]

adding joe and charley to see if there is something we can do to help in this 
kind of situation

Comment 5

[Charles Manske]

What we do in 4.x, and I now think is a good idea to repeat in mozilla Composer,
is to always include a space that is *not* part of the link whenever a link is
made, unless the link is inserted into existing text and a non-link space
already exists.
If this is true, it is very easy to move caret to after that space and continue
typing without the link. If there is any non-link text, including a space, the
new Composer is much smarter than 4.x: You can decide whether or not to continue
a link (or any other text attribute like bold...) by the direction of cursor key
movement. So if caret is at end of the link, a quick left-arrow then right-arrow
key says "Continue the link". A right-arrow then left-arrow says "Don't
continue the link." So you can see how automatically including the non-link
space completely solves this problem and still allows user choice.
This should be done in the rules code, right Joe?
Assigning to Joe.

Comment 6

[Charles Manske]

Given that you have to delete that last character after creating the link,
which puts caret into the "linked text", I don't think it's surprising that
pasting text is within the link. If your caret is at the end of the link, then
the "Discontinue Link" item is available in Format and popup context menus.
Thus I think there's really no bug here.
The only reason behavior is different in 4.x is the extra non-link space we
add, as I described above.
Should we still consider adding this extra space to the link?

Comment 7

[Joe Francis]

I dont know what we should do.  If folks want to settle on a proposal I can 
evaluate it for feasability.  cc'ing beppe/brade/sfraser.

Comment 8

[Simon Fraser [no longer active]]

I would expect it not to paste into the link, but to put the pasted text outside 
the link. 4.x is too 'link-eager' in this way, and it drives me mad.

Comment 9

[Kathleen :Brade]

We should be consistent.  For example, if I paste with the caret in between some
bold characters
  * is the pasted text bold or 
  * is the bold text split or 
  * do we paste the text before or after the bold existing text?

I would be surprised by the pasted text being pasted in a location where I
hadn't placed the caret.  My preference would be for one of the first two
choices above.

Comment 10

[Joe Francis]

futuring because I still have no idea what my marching orders are.

Comment 11

[Kathleen :Brade]

Marching Orders:
  * when pasting text, do not pick up the link unless the caret is between text 
that is in the link (if we're immediately after the link text but still in the 
link, then paste after the link.

If that's too hard, always split the link and paste the text between the two 
links.

Comment 12

[Kevin McCluskey (gone)]

Removing EDITORBASE.

Comment 13

[Joe Francis]

pushing off 098 to 099

Comment 14

[Joe Francis]

the swami says: things that will not land in 099!

Comment 15

[Kevin McCluskey (gone)]

Moving bugs to Mozilla1.1 that are not EDITORBASE+.

Comment 16

[rubydoo123]

removing myself from the cc list

Comment 17

[Joe Francis]

The days of having a half dozen milestones out in front of us to divide bugs 
between seem to be gone, though I dont know why.  Lumping everything together as 
far out as I can.  I'll pull back things that I am working on as I go.

Comment 18

[Joe Francis]

[ushing these out as far as bugzilla will let me.  I'll pull them back as I work
on them.

Comment 19

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 20

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

Fixed in bug 1357365.