Able to reproduce the issue on MAC 10.12.1 and Linux (Ubuntu 14.04) for chrome stable version 54.0.2840.98 and 54.0.2840.100. Issue is a non regression as seen from M24 - 24.0.1300.0. 

Note: Issue is not observed on Windows OS (Win 7 and Win 10).

Untriaged it so that it gets addressed.

Thanks.!

This is somewhat intricate.

Gecko (as of Firefox 50) distinguishes between double-click selection and regular selection with a mouse:
* If I double-click on the link in the example and type, I get unstyled text (i.e. the <a> node is replaced by a new, regular text node). Double-clicking and calling document.getSelection() will return the enclosing <div> as both focus and anchor. Double-clicking and calling document.execCommand("insertText", false, "foobar") also removes the <a> node as described.
* If I select the link with the mouse and type, the <a> node remains and everything I type is added within the node (i.e. it's all part of the link text). Selecting and calling document.getSelection() returns the "SelectMeAndTypeOver" text node as the anchor and the " def" text node as the focus. Selecting and calling document.execCommand("insertText", false, "foobar") replaces the text node within the <a> node (ie. "foobar" becomes the link text).
* Typing new characters right next to "SelectMeAndTypeOver" may add them to the <a> node or not depending on how the caret was placed: if I either click right next to 'S' or 'r' or move the caret with the keyboard _from_ the text towards "abc " or " def", the new text becomes a link. Conversely, if I move the caret from "abc " or " def" towards the link, the new text is added to these adjacent text nodes and do not become part of the link text.

Blink (both M54 and master) on Linux and Android:
* Double-click and type: the first character replaces the text node within the <a> node, and anything else that's typed is added to a new text node inserted between the <a> and the " def" text node. document.getSelection() returns the "SelectMeAndTypeOver" text node as both focus and anchor. Similarly, document.execCommand("insertText", false, "foobar") replaces the text node within the <a> node (ie. "foobar" becomes the link text).
* Selecting the link manually has the same behavior.
* Entering new text to the left of "SelectMeAndTypeOver" appends the contents to the existing "abc " text node (ie. it never becomes part of the link).
* Entering new text to the right of "SelectMeAndTypeOver" creates a new, unstyled text node that's inserted between <a> and the " def" text node (ie. it never becomes part of the link).

In Blink, the difference between typing and calling document.execCommand() is explained by the fact that typing causes CompositeEditCommand to delete the existing text contents ("SelectMeAndTypeOver") and then insert a new text node with the first character. All further characters are just new insertion calls, not part of the replacement.

The difference experience on Chrome for Windows is just due to the fact that double-click selection is implemented differently there to mimic the default Windows UX: double-clicking "SelectMeAndTypeOver" actually causes the space to the right of it to be selected as well. Since the space is part of a different node, the whole behavior is different and the <a> node is removed when new text is entered.

I did not test Safari, but Gnome Web/Epiphany on Linux with WebKitGTK behaves identically to Chromium. I do not have access to any machine running Microsoft Edge to check out its behavior.

With that said, I'm not entirely sure following Firefox and just getting rid of the link when double-clicking and typing is correct by definition (just expanding the contents of the <a> node looks equally correct), but what Blink's doing is definitely weird.

Hopefully yosin@ or someone else who works on editing can chime in: I'd be happy to work on a patch, but we first need to agree on what the expected behavior actually is.

First of all, thanks for detailed explanation!

I think current behavior is logical from programmer's stand point. But, as usual, UX people may have different opinion.

Please file a bug in https://github.com/w3c/editing/issues to get consensus in W3C editing Task Force.

We'll follow editing TF decision.

> Please file a bug in https://github.com/w3c/editing/issues to get consensus in W3C editing Task Force.

Done: https://github.com/w3c/editing/issues/156

Please add a comment there if I missed anything.

thanks.