No bisect needed, the change that introduced the bug is: https://codereview.chromium.org/1731903003

I'd prefer to implement line navigation in content editables using AXPosition and then return to debugging this.
There is a chance it will be resolved after we switch to text markers.

 Issue 593947  has been merged into this issue.

The issue is in Blink in AXLayoutObject::selection(). We convert the position of the focus to parent anchored equivalent. While this is fine for inline text boxes because the parent anchored equivalent position would be in a static text node, it's not okay for <br> elements because the parent is inside a spurious div element that is used as a wrapper.

mac a11y triage: nektar@, please check what bugs are left here and what are fixed

The NextAction date has arrived: 2017-09-05

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8a7e051c73bb4fdab0d517371bb932dd5191df6c

commit 8a7e051c73bb4fdab0d517371bb932dd5191df6c
Author: Nektarios <nektar@chromium.org>
Date: Mon Oct 02 10:50:52 2017

Fixes focus jumping out of Gmail compose window.

Believe it or not this was the cause of the bug whereby VoiceOver focus would jump out of any rich text field, e.g. the Gmail compose window, when the caret was moved to the end of the field and the edit field had  a blank line at the end.
It turns out the bug is not related to our focus management code., despite the fact that I spent several hours debugging it and despite the fact that VoiceOver makes spurious and unexplained calls to the NSAccessibilityFocused attribute of the WebRoot every time the caret moves.
It's also not related to the call to VisiblePosition::ToParentAnchoredEquivalent in AXLayoutObject::Selection(), even though we certainly have a bug there which causes the div that wraps a <br> element in the shadow DOM of a text field to be returned instead of the <br> element itself. I am fixing this in my blink::AXPosition/AXRange refactoring.
This took a long time to discover as seemingly more appropriate fixes like the above didn't fix this particular bug. AXGroupRole was identified after observing Safari's behavior in content editables.
R=dmazzoni@chromium.org, ellyjones@chromium.org, aleventhal@chromium.org
TESTED=Manually with Gmail and VoiceOver, browser tests

Bug:  651485 
Change-Id: I073c59db1800541a55b14fe09c346f6c4eda2b1d
Reviewed-on: https://chromium-review.googlesource.com/692958
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#505571}
[modify] https://crrev.com/8a7e051c73bb4fdab0d517371bb932dd5191df6c/content/test/data/accessibility/aria/aria-posinset-expected-mac.txt
[modify] https://crrev.com/8a7e051c73bb4fdab0d517371bb932dd5191df6c/content/test/data/accessibility/aria/aria-textbox-with-selection-expected-mac.txt
[modify] https://crrev.com/8a7e051c73bb4fdab0d517371bb932dd5191df6c/content/test/data/accessibility/html/contenteditable-with-embedded-contenteditables-expected-mac.txt
[modify] https://crrev.com/8a7e051c73bb4fdab0d517371bb932dd5191df6c/content/test/data/accessibility/html/input-radio-expected-mac.txt
[modify] https://crrev.com/8a7e051c73bb4fdab0d517371bb932dd5191df6c/ui/accessibility/platform/ax_platform_node_mac.mm