This has now relanded.
The behavior is prefable, and we create a lazily-resolved shim object if
Components is not defined. I've aliased certain Ci entries to the
associated DOM constructors (that is,
Components.interfaces.nsIXMLHttpRequest === window.XMLHttpRequest) so that
interface constants Just Work. The table of shimmed interfaces is in
nsDOMClassInfo.cpp (kInterfaceShimMap).
I've added telemetry to monitor how often the shim ends up being resolved.
Hopefully, the shim should take care of both of the compat issues we were
expecting. If we run into issues on branch, we can always flip the pref.
Cheers,
bholley
On Mon, Mar 4, 2013 at 3:10 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> 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.nsIXMLHttpRequest.HEADERS_RECEIVED instead of
> XMLHttpRequest.HEADERS_RECEIVED).
>
> 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
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
