Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.6 using chrome latest stable #62.0.3202.75 by following steps mentioned in the original comment.

This issue is also observed on older version of chrome #50.0.2624.0 as well, hence considering this to be a non-regression one and marking it as untriaged for updates from dev team.

Note: Issue is not observed on Firefox

Thanks!

Lower to Pri-3 since we don't have time to work this.

Mark WontFix since this is default event handling of "mousedown" event which is UA
dependent.

In Blink, moving focus to event target before setting selection. Edge does as same
as Chrome.

Upload to https://jsfiddle.net/bdap3v94/

Edge: before=0, after=2; same as Chrome
Firefox: before=2, after=2

Stack trace at dispatching "focus" event:
 EventDispatcher::DispatchEventAtTarget() Line 226
 EventDispatcher::Dispatch() Line 178
 FocusEvent::DispatchEvent(blink::EventDispatcher & dispatcher) Line 74
 EventDispatcher::DispatchEvent(blink::Node & node, blink::Event * event) Line 57
 Node::DispatchEventInternal(blink::Event * event) Line 2231
 EventTarget::DispatchEvent(blink::Event * event) Line 544
 Element::DispatchFocusEvent(blink::Element * old_focused_element, blink::WebFocusType type, blink::InputDeviceCapabilities * source_capabilities) Line 3039
 HTMLFormControlElement::DispatchFocusEvent(blink::Element * old_focused_element, blink::WebFocusType type, blink::InputDeviceCapabilities * source_capabilities) Line 410
 TextControlElement::DispatchFocusEvent(blink::Element * old_focused_element, blink::WebFocusType type, blink::InputDeviceCapabilities * source_capabilities) Line 91
 Document::SetFocusedElement(blink::Element * new_focused_element, const blink::FocusParams & params) Line 4521
 FocusController::SetFocusedElement(blink::Element * element, blink::Frame * new_focused_frame, const blink::FocusParams & params) Line 1251
 MouseEventManager::HandleMouseFocus(const blink::HitTestResult & hit_test_result, blink::InputDeviceCapabilities * source_capabilities) Line 496
 EventHandler::HandleMousePressEvent(const blink::WebMouseEvent & mouse_event) Line 674
 PageWidgetEventHandler::HandleMouseDown(blink::LocalFrame & main_frame, const blink::WebMouseEvent & event) Line 252
 WebViewImpl::HandleMouseDown(blink::LocalFrame & main_frame, const blink::WebMouseEvent & event) Line 484
 PageWidgetDelegate::HandleInputEvent(blink::PageWidgetEventHandler & handler, const blink::WebCoalescedInputEvent & coalesced_event, blink::LocalFrame * root) Line 166
 WebViewImpl::HandleInputEvent(const blink::WebCoalescedInputEvent & coalesced_event) Line 2094
 WebViewFrameWidget::HandleInputEvent(const blink::WebCoalescedInputEvent & event) Line 97

Thanks for looking into it

Is there a standard specification about this behavior, in addition to vendor implementations themselves?

There does not seem to be a consensus on this, as at least one major browser did it differently. 

I tend to think Firefox implementation makes more sense, and is more consistent with other event handlers:
- typing a character in an input, it is not the previous value that is sent with the onChange event, but the new value
- onScroll, it is not the previous scroll position that is sent, but the new one
- etc

I don't know the underlying challenges to achieve that, but in a developer point of view, it seems awkward to not have the caret position at the moment of the focus event.