| Bobby Holley |  Post reply |
Hi All,
This is a friendly notice that the Components object is finally about to
disappear for web content. This is something we've been planning for years,
and we believe that all the necessary pieces are now in place. The patches
are ready to land, pending a final try run.
Hopefully, this shouldn't affect you at all. Here's a brief FAQ for the
curious:
Q: What is the Components object?
A: The Components object is a Gecko-proprietary bridge from JS into various
platform features. It has historically been defined on almost all XPConnect
globals, even though it was never really meant to be exposed to web content.
Q: If it goes away, how do I use it in Mochitests?
A: If you're using Components in a content Mochitest, you should probably
be writing a chrome Mochitest instead (with a content iframe, if
necessary). But if you really need it for some reason, SpecialPowers.Cc,
SpecialPowers.Ci, etc. give you SpecialPowers-wrapped versions of the
relevant objects, letting you do privileged things. If you want access to
the raw Components object without any privilege wrapping, you can use
SpecialPowers.Components.
Q: Why didn't we do this sooner?
A: Various in-content XBL bindings depend on being able to QI DOM nodes to
arbitrary interfaces. Until recently XBL was injected directly into the
content scope, so we had to keep Components available to content as well.
Now that in-content XBL runs in a separate compartment (with its own global
and own Components object), this is a non-issue.
Q: Will this break websites?
A: Some, probably. Telemetry indicates that a bit under 10% of users
encounter at least one reference to Components during their browsing
session. Approximately half of these appear to be simple accesses of the
object itself and not any of its properties, which probably indicates
bachelor-frog browser detection of the form |if (window.Components) { /*
Firefox */ }|. The other half appears to be access to
Components.interfaces, which probably indicates that the page is pulling
DOM constants off XPCOM interfaces instead of the DOM constructor (i.e.
Components.interfaces.
XMLHttpRequest.HEADERS_
Q: 10% of websites? That sounds bad.
A: It's not 10% of websites. 10% of users encounter one or more websites
that access Components. It might be a few big sites, or a long tail of
intranet apps. The privacy constraints of Telemetry prevent us from knowing
more.
Q: Have we warned web developers that this was coming?
A: Yes. Repeatedly. Most significantly, we've been shipping a dire console
warning since Firefox 18 saying that the Components object was going away.
When Firefox 18 was a few weeks away from release, the Telemetry data
dropped sharply from 20% to the 10% we see today. This indicates that a few
web developers saw the warning and fixed their site. The rest probably need
more aggressive messaging, which is what we're about to do here. :-)
Components is not part of the web platform, and has no legitimate use by
content. It's time for it to go.
Cheers,
bholley
This is a friendly notice that the Components object is finally about to
disappear for web content. This is something we've been planning for years,
and we believe that all the necessary pieces are now in place. The patches
are ready to land, pending a final try run.
Hopefully, this shouldn't affect you at all. Here's a brief FAQ for the
curious:
Q: What is the Components object?
A: The Components object is a Gecko-proprietary bridge from JS into various
platform features. It has historically been defined on almost all XPConnect
globals, even though it was never really meant to be exposed to web content.
Q: If it goes away, how do I use it in Mochitests?
A: If you're using Components in a content Mochitest, you should probably
be writing a chrome Mochitest instead (with a content iframe, if
necessary). But if you really need it for some reason, SpecialPowers.Cc,
SpecialPowers.Ci, etc. give you SpecialPowers-wrapped versions of the
relevant objects, letting you do privileged things. If you want access to
the raw Components object without any privilege wrapping, you can use
SpecialPowers.Components.
Q: Why didn't we do this sooner?
A: Various in-content XBL bindings depend on being able to QI DOM nodes to
arbitrary interfaces. Until recently XBL was injected directly into the
content scope, so we had to keep Components available to content as well.
Now that in-content XBL runs in a separate compartment (with its own global
and own Components object), this is a non-issue.
Q: Will this break websites?
A: Some, probably. Telemetry indicates that a bit under 10% of users
encounter at least one reference to Components during their browsing
session. Approximately half of these appear to be simple accesses of the
object itself and not any of its properties, which probably indicates
bachelor-frog browser detection of the form |if (window.Components) { /*
Firefox */ }|. The other half appears to be access to
Components.interfaces, which probably indicates that the page is pulling
DOM constants off XPCOM interfaces instead of the DOM constructor (i.e.
Components.interfaces.
XMLHttpRequest.HEADERS_
Q: 10% of websites? That sounds bad.
A: It's not 10% of websites. 10% of users encounter one or more websites
that access Components. It might be a few big sites, or a long tail of
intranet apps. The privacy constraints of Telemetry prevent us from knowing
more.
Q: Have we warned web developers that this was coming?
A: Yes. Repeatedly. Most significantly, we've been shipping a dire console
warning since Firefox 18 saying that the Components object was going away.
When Firefox 18 was a few weeks away from release, the Telemetry data
dropped sharply from 20% to the 10% we see today. This indicates that a few
web developers saw the warning and fixed their site. The rest probably need
more aggressive messaging, which is what we're about to do here. :-)
Components is not part of the web platform, and has no legitimate use by
content. It's time for it to go.
Cheers,
bholley
source link: https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/dptQB8dXWp4