Now that non-libxul builds are unsupported, my understanding is that nsIContentUtils doesn't serve a useful purpose and can be removed.
And nsIContentUtils2, and maybe nsIContentUtils3 if we managed to grow that ... But yes, as long as the interface was only to allow it to be used cross-module (and there are no script consumers) you can scrap it.
Created attachment 525222 [details] [diff] [review] Patch v1 How does this look to you, Jonas?
Created attachment 525593 [details] [diff] [review] Patch v2 Unbitrotting after removal of a MOZILLA_2_0 interface.
Created attachment 525614 [details] [diff] [review] Patch v3 Removing nsLayoutModule entries, which I initially missed.
This landed: http://hg.mozilla.org/mozilla-central/rev/457757151653 and broke Windows builds: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1302810160.1302813617.29925.gz and got backed out as a result: http://hg.mozilla.org/mozilla-central/rev/026fc72b77aa
So the problem is TestChromeMargin.cpp, a Windows only cpp test. It tests a function in ns{I}ContentUtils. If you include nsContentUtils.h directly, you end up including enough of the world that you need to be in the internal API world. But I can't figure out how to get this unit test into that world. Apparently you can't just #define MOZILLA_INTERNAL_API and expect things to work. :) jimm or someone else: Any ideas on how to fix this? I'd really hate to hold this bug up on a test technicality.
On IRC, jimm gave me r+ to disable widget/tests/TestChromeMargin.cpp. I'll file a followup bug to fix and re-enable the test.
Pushed with misbehaving test disabled: http://hg.mozilla.org/mozilla-central/rev/863db843fde4
or
