From bug 27196 comment 5 by bz:

> I thing HTML is buggy if it's doing that.  I just looked, and it looks like
> it does it for the following (I'm ignoring things like referrers and base
> URIs and whatnot, just looking at origins):
> 
> 1) Canvas tainting bits.  Does this actually match implementations?  Does it
> make sense to do it that way?
> 
> 2) .frameElement, looking at effective script origins.  This is not too
> unreasonable, since effective script origins end up needing to match the
> effective script origins of everything else you're dealing with, pretty
> much, so it doesn't matter too much which settings object you use here.  At
> least in browsers that implement security membranes (which of course doesn't
> match the HTML spec, but I consider that a bug in the HTML spec).
> 
> 3)  A check in replaceState which I'm totally unclear on.  It claims to
> restrict sandboxed content, but there's nothing to indicate that the entry
> settings will be the sandboxed thing!
> 
> 4)  Location security checks.  That stuff is all broken as written up right
> now; see bug 20701.
> 
> 5)  Origin check in registerProtocolHandler.  Again, it's not clear to me
> why using the origin of the entry settings object is the right thing here. 
> I don't think it is.
> 
> 6)  Something in IsSearchProviderInstalled.
> 
> 7)  createImageBitmap.  This is similar to canvas tainting.  Except ignores
> CORS?
> 
> 8)  For EventSource, setting the origin for CORS purposes to that of the
> entry settings object.  That makes no sense to me.
> 
> 9)  For websocket, checking the scheme of the origin of the entry settings
> object, and using its origin in the websocket connection.
> 
> 10) A sanity check that all origins match in postMessage.  This part is not
> too unreasonable.