That's what the spec says, and what other browsers do. See also: rdar://problem/19640886
Created attachment 246556 [details] proposed fix
Comment on attachment 246556 [details] proposed fix Attachment 246556 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5608730104168448 New failing tests: http/tests/navigation/target-blank-opener.html
Created attachment 246563 [details] Archive of layout-test-results from ews105 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Created attachment 246584 [details] proposed fix Forgot to remove an experimental change.
Comment on attachment 246584 [details] proposed fix View in context: https://bugs.webkit.org/attachment.cgi?id=246584&action=review > Source/WebCore/loader/FrameLoader.h:110 > WEBCORE_EXPORT void loadFrameRequest(const FrameLoadRequest&, LockHistory, LockBackForwardList, // Called by submitForm, calls loadPostRequest and loadURL. > - PassRefPtr<Event>, PassRefPtr<FormState>, ShouldSendReferrer, AllowNavigationToInvalidURL); > + PassRefPtr<Event>, PassRefPtr<FormState>, ShouldSendReferrer, AllowNavigationToInvalidURL, NewFrameOpenerPolicy); This is really getting out of hand. I think we need to group these arguments all into an object rather than passing them all separately. Maybe just a struct?
I think that we already have one struct, FrameLoadRequest, but I'm not sure what belongs to it, and what doesn't. We may or may not want to try aligning with HTML5 terminology along the way. My concern is that the way the spec describes relationships between browsing contexts is quite complex.
Comment on attachment 246584 [details] proposed fix Clearing flags on attachment: 246584 Committed r180110: <http://trac.webkit.org/changeset/180110>
All reviewed patches have been landed. Closing bug.
This was in radar as rdar://problem/20306425