app:// URIs are no longer a thing. This is essentially backing out bug 1243849.

This is backing out bug 1243849.

Comment on attachment 8802118 [details] [diff] [review] Remove support for accessing the Cache API from app:// URLs and also for storing requests/responses with app:// URLs within it Review of attachment 8802118 [details] [diff] [review]: ----------------------------------------------------------------- In theory we should scrub any sqlite entries with an app:// URL, but I think we can fairly assume those don't exist in our target platforms. Is there a bug on file to remove the appId stuff from the principal? Once that happens I think we can remove the IsApp flags from dom/cache and QuotaManager, etc. Thanks!

(In reply to Ben Kelly [:bkelly] from comment #2) > In theory we should scrub any sqlite entries with an app:// URL, but I think > we can fairly assume those don't exist in our target platforms. Yes, I think so. > Is there a bug on file to remove the appId stuff from the principal? Once > that happens I think we can remove the IsApp flags from dom/cache and > QuotaManager, etc. I've been removing various notions of apps from Gecko in the past few weeks, and we're still not far enough to remove apps stuff from nsIPrincipal, but I'd like to get there soon. Bug 1306391 is the tracker I have been using for those patches. baku has asked us to not remove those before bug 1302697 is fixed so that there's still some way for add-ons to create isolated cookie jars, but since we have still some work left before we can remove all appId notions, and I doubt that bug becomes an eventual blocker. Removing the IsApp flags will break the isolated cookie jar use case for add-ons, so let's wait a bit more on that. I filed bug 1311057 to track this.

Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/aff104ad1e44 Remove support for accessing the Cache API from app:// URLs and also for storing requests/responses with app:// URLs within it; r=bkelly