jQuery 2.0 stable is just out, we made sure our JS was compatible with jQuery 1.9 a short time ago so that we could use jQuery 2 when possible.

Here it is.

- Put the library version as 1.9 since it's the API we'll keep compatibility with.
- I move jquery in it's sub folder like the rest of vendor scripts.
- renamed the jquery file with the "official" file name, we don't care it's all abstracted in the library declaration.

It's a perf thing too. Several other reasons but we should do it anyway.

(conditional comments are not great but I'd say to get rid of them the easiest is to drop support for IE8 in D8 :)

#27 core-js-jquery2-1974340-27.patch352.4 KBnod_
PASSED: [[SimpleTest]]: [MySQL] 56,141 pass(es).
[ View ]
#27 patch-nojQuery.txt1.09 KBnod_
#17 jquery-2.0.0.patch356.2 KBjbrown
PASSED: [[SimpleTest]]: [MySQL] 54,491 pass(es).
[ View ]
#17 interdiff.txt1.29 KBjbrown
#14 jquery-2.0.0.patch355.93 KBjbrown
PASSED: [[SimpleTest]]: [MySQL] 54,500 pass(es).
[ View ]
#14 interdiff.txt1.65 KBjbrown
#6 core-js-jquery2-1974340-6.patch354.75 KBnod_
FAILED: [[SimpleTest]]: [MySQL] 54,524 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
core-js-jquery2.patch352.45 KBnod_
FAILED: [[SimpleTest]]: [MySQL] 54,588 pass(es), 4 fail(s), and 0 exception(s).
[ View ]


forgot tags

Marked #1974236: Update jQuery to 2.0 as a duplicate

If we can agree on #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8), then we can just use jQuery 2.0 here. IMO, that's a better solution, but if this is the only way to get jQuery 2 into core, then so be it.

Status:Needs review» Needs work

The last submitted patch, core-js-jquery2.patch, failed testing.

One big concern: doesn't using conditional comments cause worse JS aggregation?

Status:Needs work» Needs review
new354.75 KB
FAILED: [[SimpleTest]]: [MySQL] 54,524 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

Fixed tests, they were using jquery.js where drupal.js is slightly more appropriate. That's a file we own.

@Wim, there are concerns, yes. It's more fun to talk with a green patch around though, just in case.

For aggregation, we'll all be using SPDY soon right? :) And it can't be much worse than what it currently is.

SPDY is still far away from being used on the majority of sites.

And yes, JS aggregation is already very crappy in core, so you're right, it can't be much worse.

SPDY is currently used by 52% of browsers http://caniuse.com/spdy. However make one or two more requests for jQuery I don't think it is a big deal.

Status:Needs review» Needs work

The last submitted patch, core-js-jquery2-1974340-6.patch, failed testing.

Status:Needs work» Needs review

According to the jquery site, we should use 1.9 if we support IE8. The dual approach isn't recommended. Certainly because IE19 and IE10 can render inccorrectly if they are run in "compatibility mode".

If we all know these concerns and we still think this is the way to go I'm fine with that. I don't use IE anyways ;)


You can (and should) continue to use jQuery 1.9 (and the upcoming 1.10) on web sites that need to accommodate older browsers.

No more support for IE 6/7/8: Remember that this can also affect IE9 and even IE10 if they are used in their “Compatibility View” modes that emulate older versions. To prevent these newer IE versions from slipping back into prehistoric modes, we suggest you always use an X-UA-Compatible tag or HTTP header. If you can use the HTTP header it is slightly better for performance because it avoids a potential browser parser restart.

#8: Browsers != servers. An additional request can make a huge difference for a highly optimized site.

jQuery blog telling us use 2.0 on IE9 / 10 could be not safely. and suggest you to add X-UA-Compatible to force it rendering IE9 / 10 mode. We fixed the X-UA-Compatible issue: #1203112: Add X-UA-Compatible HTTP header. So I don't think it will be a problem.

dual approach always better than loading single script. :)

#11 Handling static requests is not a problem for good server. For a "highly optimized site", the same server that serves 100 PHP requests/s (that already means thousands of online users) can easily handle 100x number of requests for static files, a server that is optimized for static files even does it better. Adding 1% more will change nothing. So servers hardly play a role here.

Title:Use jQuery 2 in better browsers than IE8Use jQuery 2 in browsers better than IE8
new1.65 KB
new355.93 KB
PASSED: [[SimpleTest]]: [MySQL] 54,500 pass(es).
[ View ]


Also, why aren't we supplying the minified version?

Because Drupal isn't relased yet. Helps debugging.

new1.29 KB
new356.2 KB
PASSED: [[SimpleTest]]: [MySQL] 54,491 pass(es).
[ View ]


#13: I was not talking at all about back-end performance or server load. I was talking about front-end performance ;) There a single additional HTTP request can make a very big difference. Especially on optimized sites.

Is there an issue to fix the problems with the aggregation?

(I would think its best not to aggregate the bigger library files such as jquery at all?)

+++ b/core/misc/jquery/jquery-2.0.0.jsundefined
@@ -9574,24 +8719,37 @@ jQuery.each( { Height: "height", Width: "width" }, function( name, type ) {
+jQuery.fn.size = function() {
+ return this.length;
+jQuery.fn.andSelf = jQuery.fn.addBack;

Is there any 3rd JS in CORE using these 2 function (and other deprecated function) ?

(I would think its best not to aggregate the bigger library files such as jquery at all?)

Yeah, on our non-Drupal application, we split it into verdor.js / app.js.

http://brunch.io/ framework do the same way:
"This is better solution for browser caching than using one file, because you change dependencies not as often as you change your application code."

#19/#20: There is no single best way. For some sites it's better to have jQuery aggregated with the rest of the JS, for others it's the other way around. The only rule is that we shouldn't make it impossible. That's all I've been saying, really :)

This feels like a bad idea, mainly for reasons stated above (extra request, ...), but I can't really think of a better solution.

I could live with this, but I feel like there needs to be an easy way to opt-out and force it to use either 1.9 or 2.0 (in code or settings), so people who don't support IE8 can effectively drop support and still be able to aggregate jQuery with the rest.

This is a release blocker for me, but I'd much rather figure out #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8) or just drop support for IE8 altogether than mess around with dual versions here.

Who cares about the extra request can simply implement hook_library_info_alter() to put jQuery 1.9 unconditionnally back. I think this patch could get in, then if we decide to remove JS support for IE8, we could easily remove jQuery 1.9 without much verification.

@23: This feels like a safer solution than #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8) as I feel like IE8 will still be a factor come D8 release-day. Contrib can still come up with a no-js solution for IE8.

@24: Granted, easy enough for me.

Title:Use jQuery 2 in browsers better than IE8Update to jQuery 2
Status:Postponed» Needs review
new1.09 KB
new352.4 KB
PASSED: [[SimpleTest]]: [MySQL] 56,141 pass(es).
[ View ]

We're not supporting IE8 anymore #1993322: [Meta] Drop IE8 support, we only need jQuery 2, yay!

jQuery 1.9 can be added back in the IE8 module (patches welcome).

Status:Needs review» Reviewed & tested by the community

This is fine!

+1. So happy about this.

Status:Reviewed & tested by the community» Fixed

Committed to 8.x. Thanks!

Issue tags:+ie8

Added to IE8 module: http://drupalcode.org/project/ie8.git/blobdiff/0dafe7d352acc87914ba279d6...

Tagging to keep track of issues backported.

updated the change notice we used for jQuery 1.9: https://drupal.org/node/1966536

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

conditional comments comment.