I've just spent a bunch of time working out why we have a content.xpt being generated that isn't packaged and doesn't break the build. It turns out that bug 500883 landed canvas3D into core, ifdeffing most of it, but not the inclusion in the build of nsICanvasGLPrivate. Not sure if the best solution is just to package it for everyone or temporarily remove it from the build with an ifdef. Oh and I expect this may have been included in FF 3.6 alpha 1 so if we want to remove it from the build we need to include it in removed-files.in until such time as it is actually added as otherwise if we happen to add it to a different .xpt and not clean up content.xpt FF 3.6 alpha 1 will have .xpt files with duplicate definitions.

Hm, where is nsICanvasGLPrivate being used? We should just ifdef it out, all the canvas3d stuff is going to get a large makeover/cleanup soon.

iirc it is just in the code that is ifdef MOZ_ENABLE_CANVAS3D - I haven't taken a close look though.

I was going to do the whole deal, packaging and removing content_canvas.xpt in ifdefs, but then I discovered that --enable-canvas3d doesn't actually build, which makes it a little hard to test packaging. So, this'll get rid of the bogus content.xpt we shipped in 3.6a1/Mac, and probably set it up so that if when it starts building it still has an idl, it'll wind up in a properly named (but not packaged) xpt.

Comment on attachment 395071 [details] [diff] [review] Stop the bleeding I was going to say you should preemptively handle it in packaging, but since none of the rest of the bits get packaged yet, this seems fine.

Comment on attachment 395071 [details] [diff] [review] Stop the bleeding We'll wind up with this on 1.9.2, whether it happens here and now or from nthomas having to do it in a bug named something like "test update from 3.6a1 to make sure everything works okay."