Extensions are not a liked configuration mechanism (Bug 713802 comment 29). nsGIOProtocolHandler.cpp need not be an extension. It can even be compiled into libxul, because GIO will already be required by the icon image decoder. GIO is part of the GLib version Firefox require's now. Ideally we'd still keep a build config option, perhaps --enable-gio-protocol-handler, because this adds protocols not normally handled by web browsers. Not sure where the code should move to. network/system/ perhaps. There is already quite a bit of gio code in libmozgnome.so, and that will no longer depend on GNOME when GnomeVFS is dropped, so perhaps it can move to toolkit/system. (That whole component could be built into libxul.)
(In reply to Karl Tomlinson (:karlt) from comment #0) > (That whole component could be built into libxul.) Only when gnomevfs support is disabled. Which leads to another question: at what point can we consider removing gnomevfs support code.
GnomeVFS support is disabled in Firefox and I assume it can be disabled on comm-central too, now that Thunderbird builds are on CentOS 6. There isn't much reason for keeping GnomeVFS support around. The only benefits of having it still there are it makes it easier to re-enable in case we discover some unforeseen reason to do so, or perhaps to make it easier for RedHat to support EL 5.8. Neither of those are really reasons not to build in libmozgnome, assuming build changes can be reverted easily if necessary. RedHat will have their own builds for EL 5.8, so they can sort out necessary dependencies. I expect the GnomeVFS code can be removed altogether once 18 is shipped with GIO, or perhaps before that.
(In reply to Karl Tomlinson (:karlt) from comment #2) > Neither of those are really reasons not to build in libmozgnome, assuming > build changes can be reverted easily if necessary. We can ifdef the component being built separately, too.
Fixed in bug 1344038.