move nsGIOProtocolHandler.cpp out of extensions

RESOLVED DUPLICATE of bug 1344038

Status

()

Core
Build Config
RESOLVED DUPLICATE of bug 1344038
5 years ago
3 months ago

People

(Reporter: karlt, Unassigned)

Tracking

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 2

5 years ago
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.
(Reporter)

Comment 4

3 months ago
Fixed in bug 1344038.
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1344038
You need to log in before you can comment on or make changes to this bug.