Add accessor for SecurityOrigin::m_domainWasSetInDOM

• Component: DOM
• Status: RESOLVED FIXED

[Adam Barth]

It will help Chromium unfork SecurityOrigin.cpp if we add an accessor for SecurityOrigin::m_domainWasSetInDOM.  If this flag is false, Chromium can do a same-origin check in one pointer comparison by atomizing the toString() of the SecurityOrigin (with some other caveats).

Currently they have YASOTSF (Yet Another SecurityOrigin toString Function) called SecurityOrigin::securityToken that knows about m_domainWasSetInDOM.  Adding an accessor for m_domainWasSetInDOM seems better than adding this function to our tree.

Now, if only I can get rid of the YASOTSF called SecurityOrigin::databaseIdentifier, my plans for grand unification of the SecurityOrigin toString methods will be complete!

Patch forthcoming.

[Adam Barth]

Created attachment 24594 [details]
le patch

[Sam Weinig]

Comment on attachment 24594 [details]
le patch

+ * Copyright (C) 2007-2008 Apple Inc. All rights reserved.
We like to use comma delineated years.

         void setDomainFromDOM(const String& newDomain);
 
+        bool domainWasSetInDOM() const { return m_domainWasSetInDOM; }
These should be paragraphed together.

I am a little unclear about why this is necessary, the SecurityOrigin it self should be sufficient for a fast compare.  Perhaps we can remove this later.

[Adam Barth]

Fixed in http://trac.webkit.org/changeset/37814

> I am a little unclear about why this is necessary, the SecurityOrigin it self
> should be sufficient for a fast compare.  Perhaps we can remove this later.

Yeah, maybe there is a better long term solution here.  I think the fast path for comparing SecurityOrigins in V8 gets inlined into the JITed code and they want to avoid the function call overhead.  (I might be wrong about this, V8 is pretty mysterious to me.)  It's similar to how JavaScriptCore doesn't bother calling SecurityOrigin::canAccess if a frame is accessing itself (the most common case) but taken to a little further extreme.