Rick, do you know anyone from Blink team, who can tell if |event.stopPropagation()| should prevent opening a child window?

Yes it should still open a window.  preventDefault() is what would suppress that.

This is defined at https://html.spec.whatwg.org/multipage/semantics.html#the-a-element which says it's the "activation behavior" of the "a" element which causes navigation.
Step 18 at https://dom.spec.whatwg.org/#dispatching-events shows that the activation behavior is run when the "canceled flag" is unset (and elsewhere in the DOM spec you can see that it's preventDefault that sets the canceled flag, not stopPropagation).

Safari also appears to behave correctly: http://output.jsbin.com/buhibo/1

stopPropagation just prevents other event listeners (which occur later in the dispatch sequence) from seeing the event.  The browser's own behavior isn't considered an event listener (it's the thing that dispatched the event).

Thank you! Both Safari on iOS 10.2 and Desktop Safari 10.0.2 do not open a child window (I could not open http://output.jsbin.com/buhibo/1, so used my test case). I will file radar for behavior.

rdar://30360766

Oh I'm sorry, I think I misunderstood your question!  I thought you were asking about whether 'stopPropagation()' should suppress the default navigation behavior of clicking on a link or not (it should not, and does not in Safari).  So I think the 'stopPropagation' in here is irrelevant to the behavior you're seeing.

As for whether it should be possible to BOTH open a new tab/window AND navigate the current page in this way: that's a good question.  I think so (I'd expect setting location.href to take effect asynchronously and that appears to be how Chrome, Firefox and Edge all behave).  But it's not clear to me from the spec: https://html.spec.whatwg.org/#location-object-setter-navigate.  If setting the href is allowed to proceed entirely synchronously than by the time we get to handling the default action for the click, it may be too late (eg. the DOM for the source document may be gone, so there's no longer any 'a' element for the click to activate).  Maybe it's an undefined race?  It's also possible there's some pop-up blocking heuristics here.  Anyway the fact that Safari differs from the behavior Chrome, Firefox and Edge all have is an interop bug that's worth raising with Apple - thanks!

In case it's not obvious, the way to do something like this that doesn't depend on hard-to-reason-about timing is something like:

<a id='link'
   href='https://yahoo.com'
   target='_blank'
   onclick='setTimeout(function() { location.href="https://www.google.com/"; }, 0);'>
  Open Child and navigate parent
</a>

So example from comment #6 works fine in Desktop Safari, but does not work in Mobile Safari. Updated radar with that information.

No activity in radar since our last post in February 2017.
Is this still an issue in iOS11?

The test is still failing on iOS 11.3