On Tue, Mar 5, 2013 at 6:16 AM, Benjamin Smedberg <benja...@smedbergs.us>wrote:
> On 3/4/2013 6:10 PM, Bobby Holley wrote:
>
>> 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).
>>
> Is there a particular reason we aren't just making these cases continue to
> work? I understand that we don't want to expose the *current* Components
> object for a bunch of compelling reasons. But couldn't we have a new object
> with specific compatibility behaviors so that existing sites which use
> Components for detection or for specific interface consts to continue to
> work?
>
> e.g. nsIDOMComponentsShim -> interfaces -> nsIXMLHttpRequest. list of
> consts
>
Defining an empty "window.Components" property to appease browser
detection wouldn't be that hard, but it makes things confusing, and has the
cost of perpetuating non-standard behavior on the web. This in turn makes
it more difficult to build a new interoperable implementation like Servo.
In my opinion, we should treat any such hacks as stop-gap measures, rather
than permanent ones. For example, when I removed enablePrivilege, the
MathJax library broke because of the disappearance of the |window.netscape|
object. They were embarrassed and fixed their code, and I landed and empty
|netscape| object for compatibility while the update makes its way around
the web. But I still plan to remove it eventually. So while it's possible
that we may need to do something like this, I only want to do it after
lighting a fire under developers to fix their stuff. We have no idea how
many sites and what kind of sites we're dealing with, and won't unless we
land this and let people file bugs.
Defining a shim for interface constants is significantly more complicated.
While possible, it represents a fair amount of engineering effort that I'd
like to avoid, and forces us to maintain nsIDOMFoo interfaces that would
otherwise go away with the WebIDL transition. We may yet have to do
something like this, but it's a high bar.
bholley
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
