[webkit-reviews] review requested: [Bug 28986] Add support for noreferrer link relation : [Attachment 41062] Attempt #3

[bugzilla-daemon at webkit.org]

Nate Chapin <japhet at chromium.org> has asked  for review:
Bug 28986: Add support for noreferrer link relation
https://bugs.webkit.org/show_bug.cgi?id=28986

Attachment 41062: Attempt #3
https://bugs.webkit.org/attachment.cgi?id=41062&action=review

------- Additional Comments from Nate Chapin <japhet at chromium.org>
Requested ASSERT added.

Changed implementation of rel attribute in HTMLAnchorElement.  Link relations
are stored as a bitmask (only one bit is used at the moment, but the
definitions are there and ready to be uncommented as more are implemented). 
HTMLAnchorElement::setRel() parses a rel string using ClassNames and
initializes the bitmask.  hasRel() returns whether a given link relation is set
based on the bitmask.  I'll plan on renaming ClassNames in a later patch.

> One thing I didn't ask about originally - what makes us believe that it's ok
> not to set the internal opener attribute? One example that makes me curious
is:
> can we programmatically navigate a frame with a different origin, but whose
> opener is same origin? The tests are in FrameLoader::shouldAllowNavigation(),

> and they rely on opener() value.
> 
> Tentatively, I'd say yes, but the patch appears to prevent this.

My interpretation of what the spec says about rel="noreferrer" is that it is
essentially a request by the current page for a total severing of any
connection between it and a destination page.  As such, unless I'm
misinterpreting your question, I think we want to just not set the internal
opener attribute to prevent any connection to the opener under any
circumstances, even if it is same origin.