nsIPluginHost doesn't need to have so many methods in it any more. We should minimize it to the methods exposed to JS.
Created attachment 533409 [details] [diff] [review] fix v1.1 Build fixes.
Comment on attachment 533409 [details] [diff] [review] fix v1.1 r=jst
pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/d3d024159f8b
Nobody should be mocking pluginhost. We should mark it [builtinclass] so that doesn't work.
Benjamin, why not? Making our services mock-able can make a huge difference to testability. Dave, you wrote at least one of the tests that mocks pluginhost: https://hg.mozilla.org/mozilla-central/rev/95ece7200b56 Can you see a way to work around this?
(In reply to :Irving Reid from comment #7) > Benjamin, why not? Making our services mock-able can make a huge difference > to testability. > > > Dave, you wrote at least one of the tests that mocks pluginhost: > https://hg.mozilla.org/mozilla-central/rev/95ece7200b56 > > Can you see a way to work around this? Nothing particularly nice, no.
Pluginhost is not a standalone component; it is tightly bound up with nsObjectLoadingContent/nsPluginInstanceOwner and the nsPluginTag implementation. I can certainly see us adding a testing mode to blocklist/EM to use an alternate contractID for the pluginhost just in xpcshell tests for those components. That would certainly be more reasonable than trying to replace the real pluginhost.