Bug 30781 – noreferrer links currently suppress window.opener in origin frame incorrectly

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Nate Chapin]

A noreferrer link should only suppress window.opener if the link is a <a rel="noreferrer" target="_blank">, and only in the new frame.  I am incorrectly calling setOpener(0) for the original FrameLoader, causing window.opener to be nulled in the origin frame (which shouldn't happen in any case, even if we're opening a noreferrer link in the current frame).

[Nate Chapin]

Created attachment 41880 [details]
patch + updated layout test

[Alexey Proskuryakov]

Comment on attachment 41880 [details]
patch + updated layout test

r=me

It would help to have the reasons for this change documented here for posterity (the bug description says "should", but doesn't explain why - are we following the spec? other browser's behavior? fixing website compatibility? just pure common sense?). This change seems logical though.

[Nate Chapin]

(In reply to comment #2)
> (From update of attachment 41880 [details])
> r=me
> 
> It would help to have the reasons for this change documented here for posterity
> (the bug description says "should", but doesn't explain why - are we following
> the spec? other browser's behavior? fixing website compatibility? just pure
> common sense?). This change seems logical though.

Certainly, sorry for not including that.

After discussions with a couple of chromium folks that initially helped me realize something wasn't quite right, I posted to whatwg ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023800.html )

The spec (http://www.whatwg.org/specs/web-apps/current-work/#link-type-noreferrer) only states that opener should remain null when a noreferrer link is opened in a new browsing context.  In the absence of specific instructions on what to do when opened in an existing context, I seem to have extrapolated incorrectly.

[WebKit Commit Bot]

Comment on attachment 41880 [details]
patch + updated layout test

Rejecting patch 41880 from commit-queue.

Failed to run "['git', 'svn', 'dcommit']" exit_code: 1
Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	LayoutTests/ChangeLog
	M	LayoutTests/http/tests/navigation/no-referrer-reset-expected.txt
	M	LayoutTests/http/tests/navigation/no-referrer-reset.html
	M	WebCore/ChangeLog
	M	WebCore/loader/FrameLoader.cpp
Merge conflict during commit: MERGE request failed on '/repository/webkit/trunk': Conflict at '/trunk/WebCore/ChangeLog' at /usr/local/libexec/git-core//git-svn line 469

[Eric Seidel (no email)]

Comment on attachment 41880 [details]
patch + updated layout test

bugzilla-tool has code to catch this type of error.  That's not an expected error from git svn.  Perhaps it was related the fact that svn.webkit.org went down right as/after this commit happened...  Trying again.

[WebKit Commit Bot]

Comment on attachment 41880 [details]
patch + updated layout test

Rejecting patch 41880 from commit-queue.

Failed to run "WebKitTools/Scripts/build-webkit" exit_code: 1
Last 500 characters of output:
l/Projects/build/WebCore.build/Release/WebCore.build/Script-5D0D540D0E9862F60029E223.sh

Touch /Users/eseidel/Projects/build/Release/WebCore.framework
    cd /Users/eseidel/Projects/CommitQueue/WebCore
    /usr/bin/touch -c /Users/eseidel/Projects/build/Release/WebCore.framework
** BUILD FAILED **

The following build commands failed:
Derived Sources:
	PhaseScriptExecution "/Users/eseidel/Projects/build/WebCore.build/Release/Derived Sources.build/Script-DD041FBD09D9DDBE0010AF2A.sh"
(1 failure)

[Eric Seidel (no email)]

Comment on attachment 41880 [details]
patch + updated layout test

Some cosmic power does not want this patch landed.  Lets try again, this could be exciting! :)

[WebKit Commit Bot]

Comment on attachment 41880 [details]
patch + updated layout test

Clearing flags on attachment: 41880

Committed r50092: <http://trac.webkit.org/changeset/50092>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.