The opposite is true of IE8 (which we consider an archaic, or non-modern browser) where Object.definePropert(y|ies) is actually limited to DOM nodes. jQuery 2.0's support is focused on modern browsers that correctly implement ES5 and DOM APIs per standards; jQuery 1.9.x should be used for browsers that do not meet these basic requirements.

If we're not going to support half of the Android installed base in 2.0, there will be more to do here. Our message will need to be that 1.9 is the go-to version not only for oldIE, but for any code that needs to be run on older systems. I *think* that still makes a lot of sense but it changes the message from the public perception that "jQuery 2.0 is the same as 1.9 but without oldIE support."

I'll reopen this ticket so the issue won't get lost, but tend to agree with rwaldron that we don't want to lobotomize and bloat 2.0 further to support ancient browsers, no matter their source. Other thoughts?

It seems to me like support for 2.0 has always been a question of guidelines and rules-of-thumb rather than hard and fast principles—how much must we do suboptimally (in terms of size/performance/security/etc.) to get a sufficiently accessible build.

Supporting old Android wouldn't cost many bytes, but might cost performance (if going back to the indexOf cache lookups) or clean interfaces (if going back to expandos).

Man, this is a wonderfully revealing bug. I'd like to make an argument very close to Rick's thoughts on the topic. Richard's concern about an accessible build has been our overarching concern since the beginning. I don't think that concern should go away, but I would argue that the achievement of an accessible build should not be at the impending expense of the evangelistic promotion of ES5. jQuery 2.0 can make javascript easier by heavily leaning on the future of web standards, with the side-effect of spreading a natural inclination towards the use of the future-proof. As you all know, I don't want to forget those who have to support old browsers and lacking environments, but we now have a reasonable venue for acknowledging those environments that have support for the progressive. We have an opportunity for a more widespread vision for jQuery 2.0 and it can start with the decision we make on this ticket.

I hate to be the one always peeing on the parade but we'd better make sure we have a decent solution for people who wish to use 2.0 for modern browsers and 1.x for oldies on the same page, and that no matter what we decide "oldies" finally means.

When it's old IE vs the world, it's quite easy and non-intrusive (conditional comments) but when trying to differentiate between different webkits, we may very well have to resort to feature inference if not browser sniffing, a clear show-stopper.

Also, I find it really really strange we're considering a browser that has more than half the shares of a widespread OS to be "old". Let's keep in mind we're talking cellphones, a market where a 18 months old device won't get any more update. We'll have devices with this version of webkit for years.

Regarding this specific issue, the bug here is not about the browser not implementing ES5 but about it not supporting defineProperty on DOM objects, huge difference. It's a bug all-right, but the browser *is* modern (it does implement the ES5 and the DOM APIs... just not at the same time it seems :P)

...we'd better make sure we have a decent solution for people who wish to use 2.0 for modern browsers and 1.x for oldies on the same page...

I feel like this is a nice-to-have, not a requirement. I'll reiterate this as much as I have to: jQuery 1.x is a first-class citizen. Actually, it is THE first class citizen of the jQuery world. jQuery 1.x should be everybody's FIRST choice; it is !#1 after all ;-)

jQuery 2.x is what jQuery will be at some unknown point in the future. The fact that we've started on it already is just a bonus. Honestly, we could probably get away with not having any guarantee about what environment it works in. It's obviously beneficial to actually have a concise, explicit answer for the environments in which it will work; and having that answer result in the largest number of environments is ideal. But the goal for 2.x should definitely be to embrace properly implemented newer standards. We should slash as much code as possible and use 2.x as something to point to and yell at standards bodies and browser vendors about. "Why is this so difficult?" "Why is there so much code?" "This is inefficient." "Browsers are incompatible on this feature." etc. etc.

jQuery 1.x is where it's at. Stop hating.

</rant>

I'm going to try to summarize some points here...

Returning to the indexOf approach, which will kill performance (O(1) -> O(n)) is not an option. Returning to the 1.9.x implementation for the sake of an incomplete browser (that could just as easily use a 1.9.x release) is an option, but one that we should reject—why punish the entire modern desktop ecosystem for the sake of a old mobile browser? We've never done that before and we shouldn't start now.

I'd go so far as to say that ES5 implementation completeness should be part of the browser (desktop and mobile) grading system, with severe penalties for not being in compliance.

We need to stop looking at this like 1.9.x vs 2.0.x and be "ok" with shipping both—they have compatible APIs, that's all that matters.

@jaubourg...

Regarding this specific issue, the bug here is not about the browser not implementing ES5 but about it not supporting defineProperty on DOM objects, huge difference. It's a bug all-right, but the browser *is* modern (it does implement the ES5 and the DOM APIs... just not at the same time it seems :P)

That's completely contradictory to the facts. The implementation is broken and incomplete: Object.definePropert(y|ies) specification does not have normative prose that allows implementations the discretion to "pick and choose" what object's can have properties defined on it. It was broken when IE8 limited the implementation to DOM Nodes and it's broken when old WebKit limits to non-DOM Nodes.

That said, @gibson042 just had an idea... we'll get back to you all shortly

@gibson042 and I have worked out the solution, which basically boils down to:

var shimDefine = Object.defineProperties || jQuery.extend;

Patch to follow.

Fix #13494: Fallback defineProperties to jQuery.extend. Close gh-1182.

Android<4 (ancient WebKit) doesn't have full ES5 support.

Changeset: 85f1985f2444da01054800d6f41c3a6057da2e16