These objects shouldn't be exposed to content, I'd think.

I tried doing this, but it breaks SpecialPowers bits like service = SpecialPowers.Cc[className] .getService(SpecialPowers.Ci[interfaceName]); from testing/mochitest/tests/SimpleTest/MemoryStats.js Need to think about whether we can work around that.

Components and friends should not be exposed to content anyway. MozReview-Commit-ID: 4kCeBcIf9nt

Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4d4d373e1619 part 1. Remove the DOM_OBJECT flag from various Components classinfo. r=kmag https://hg.mozilla.org/integration/mozilla-inbound/rev/9349d1b031c9 part 2. Remove the now-unused getComponentsForScope API. r=kmag

Backed out changeset 4d4d373e1619 (bug 1389581) mochitest failures Permission denied to create wrapper for object of class XPCComponents_Interfaces on a CLOSED TREE Failure push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=0c7442ef9bbd58b45ddec508edae705e2bec0649 Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=170964622&repo=mozilla-inbound&lineNumber=8925 Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/90b479bd9750307dd183e2f6691e4ead4bf2c39d

Backout by ccoroiu@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/d9b6670a53cc Backed out changeset 9349d1b031c9 for mochitest failures Permission denied to create wrapper for object of class XPCComponents_Interfaces on a CLOSED TREE

Hrm. Looks like that test is only run in non-e10s mode. And not on Mac. And we don't run non-e10s mochitests on Linux64 at all, apparently, or Linux32 opt, for that matter... I'll fix the silly test and just go back to doing -p all -u all try pushes for everything, I guess, if we have tier 1 test coverage artificially restricted like this. :(

we still run non e10s mochitests on linux32-debug (look at mozilla-central). I suspect in 2 months we won't have that anymore as our primary reason for keeping the double coverage is android fennec which will be geckoview and running with e10s in the near future.

Non-e10s tests only run on win32 these days, because we mostly don't care about them, but we sort of care about them. I've run into this too :(

> we still run non e10s mochitests on linux32-debug (look at mozilla-central) Yes, I'm aware of that now. What that means is that I _have_ to include linux32-debug in all my try pushes. > I suspect in 2 months we won't have that anymore We better fix all the "skip-if = e10s" tests, then.

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #10) > > I suspect in 2 months we won't have that anymore > > We better fix all the "skip-if = e10s" tests, then. During the initial push to ship e10s, we triaged all of the tests that were skipped in e10s mode. All of the ones that were important for e10s should have been fixed, so unless new ones have been added, this shouldn't be a major concern.

Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/35da0017040e part 1. Remove the DOM_OBJECT flag from various Components classinfo. r=kmag https://hg.mozilla.org/integration/mozilla-inbound/rev/825bb50e3922 part 2. Remove the now-unused getComponentsForScope API. r=kmag

https://hg.mozilla.org/mozilla-central/rev/35da0017040e https://hg.mozilla.org/mozilla-central/rev/825bb50e3922