This is needed for jars for app cache (for a new upcoming variant of a patch that doesn't make netwerk use nsISSM). Since we don't want necko include nsISSM, we cannot actually use nsIScriptSecurityManager::NO_APP_ID to check whether the load context's extended origin is really "extended". Also, it's not probably the correct way anyway. For app cache data jars I'm adding extendedOrigin string to the groupID identifying the cache (groupID actually is the URL of the offline app cache manifest). For back/forward compatibility when looking for a cache or creating a new one, I must omit adding this extended origin string to the groupID, when load comes from a "normal" web content app cache page. So, I need a convenience and correct way to determine whether extendedOrigin is extended or just a "normal" origin of a URI. Option: - expose also "origin" that I can compare to - expose bool isExtended - add an arg to GetExtendedOrigin like bool aOnlyIfExtended

extendedOrigin == origin if and only if appid==0 && isInBrowserElement==false

Please see bug 756717 comment 7.

(In reply to Jonas Sicking (:sicking) from comment #1) > extendedOrigin == origin if and only if appid==0 && > isInBrowserElement==false You mean appid==nsIScriptSecurityManager::NO_APP_ID, don't you? Or would you agree to just compare to 0? And do you really believe it is the correct way to do this check?

I'm fine with moving that constant definition somewhere else. However I don't quite understand the why you can't use extendedOrigin. I know we can't use it in localStorage because the localStorage code uses reversed domain names in order to calculate quota on a eTLD+1 basis. Are we needing to do something similar for appcache?

> I need a convenience and correct way to determine whether extendedOrigin > is extended or just a "normal" origin of a URI. if (origin == loadContext.GetExtendedOrigin(URI)) ? :)

(In reply to Honza Bambas (:mayhemer) from comment #0) > For app cache data jars I'm adding extendedOrigin string to the groupID > identifying the cache (groupID actually is the URL of the offline app cache > manifest). Ah! Now I get it, that makes sense. What I would propose that you do is to look for |appid == 0 && !isInBrowserElement| and if that is true, you append the appid and isInBrowserElement flag to the groupID. I can't think of a really great solution for where to put the constant definition. It really sucks that we have no place for putting security infrastructure which Necko and the rest of gecko can use, but that's absolutely out-of-scope for this bug. The best solution I can think of is to put a #define in NetUtil.h (or somewhere else) which defines NECKO_NO_APP_ID and then leave a comment both there and in nsIScriptSecurityManager.h to tell people to update both places if one is updated. I'd declare the whole 'extendedOrigin' idea a dud at this point. I think only indexedDB is going to end up using it.

(In reply to Jonas Sicking (:sicking) from comment #6) > (In reply to Honza Bambas (:mayhemer) from comment #0) > > For app cache data jars I'm adding extendedOrigin string to the groupID > > identifying the cache (groupID actually is the URL of the offline app cache > > manifest). > > Ah! Now I get it, that makes sense. > > What I would propose that you do is to look for |appid == 0 && > !isInBrowserElement| and if that is true, you append the appid and > isInBrowserElement flag to the groupID. > > I can't think of a really great solution for where to put the constant > definition. It really sucks that we have no place for putting security > infrastructure which Necko and the rest of gecko can use, but that's > absolutely out-of-scope for this bug. > > The best solution I can think of is to put a #define in NetUtil.h (or > somewhere else) which defines NECKO_NO_APP_ID and then leave a comment both > there and in nsIScriptSecurityManager.h to tell people to update both places > if one is updated. > > I'd declare the whole 'extendedOrigin' idea a dud at this point. I think > only indexedDB is going to end up using it. This is what I needed to here. Thanks Jonas. Since I presume extendedOrigin is never (or at least for a long) about to be based on something different then appid and ismozbrwouser then: - I'll stop using extendedOrigin as suffix for groupID - I'll add constant NECKO_NO_APP_ID=0 (I believe as a temp fix only) to NetUtil.h - I'll build the groupID suffix my self from appID and mozbrowser flag values directly This bug is then probably WONTFIX. I'll close it when the work on app cache jars is done.

soundsgood. Thanks!