Update to jQuery 1.9

Let's get it in.

Yep. Done.

@nod_ also, the introduction of jquery-migrate might be an awesome tool for finding any issues with our implementation of jquery 1.8.

The jQuery Migrate plugin can be used with either 1.9 or 2.0 to detect deprecated and removed features, or to restore old features for those sticky situations where you need old code to run with new jQuery. The plugin and the messages it generates are documented in the project README.

some 3rd scripts in CORE still uses $.browser and other deprecated features. jquery-migrate is required.

What needs to happen to get this to RTBC? Just test most things to make sure nothing is obviously broken? AFAICT most changes are trivial? Or is it that you suspect lots of regressions due to subtle jQuery API changes?

Ok :)

The CKEditor module had to introduce a hack due to a huge bug in all jQuery versions below jQuery 1.9. Since that would be fixed by this patch, it should also remove that hack. Patch attached.

Per the warning on http://api.jquery.com/removeProp/, do not use removeProp to remove DOM standard properties like `checked` or `disabled`. Set their properties to `false` instead: `.prop("disabled", false)`

dmethvin, great catch. I had to read both http://api.jquery.com/removeProp/ and http://api.jquery.com/prop/ to grok the difference here. Essentially it boils down to this.

Let's assume we have an input element saved to the variable elem. It has a property disabled that currently is true. This is the result of the two approaches. The value of the disabled property is given as a comment after each statement.

elem.prop('disabled', false); // false
elem.removeProp('disabled'); // undefined

I've updated the instances in the patch where we should be using prop(property, boolean) instead of removeProp().

Could we have the jQuery library in a separate patch? Even better, all these changes are valid for jQuery 1.8 too.

jcisio, what do you see as the benefit of pulling the compatibility changes in the patch apart from the update of jQuery 1.9? I'd like to understand better the motivation before we consume an hour's worth of developer time on a patch update that might produce the same result in the end.

It should take less than 1 minute to exclude the core/misc/jquery.* from the patch, then add them in a separate patch. We usually do it that way. It's a bit easier to review, and we'll know the size of the "real" patch.

Well, I was trying to reroll it into two separate patchs. But it looks like from #12 there is unccessary change in a non JS file (overlay.module), so I can't do it quickly.

Here is a direct reroll from #18.

jcisio, cool, thanks for pulling them apart. If both patches come back green, we can consider them for commit.

I sent nod_ a note about the overlay change and although it's needed, it doesn't need to be in this patch.

Let's wait for the bot!

jQuery.ba-bbq is a patched version. can it add comments on the top of file.

@everyone, there's something that I cannot understand.

At
#1175830: Update to jQuery UI 1.10.2
we updated JQuery UI to version 1.10. So, why do we need an update to 1.9? I'm a bit confused, but maybe this is something I am misunderstanding (and in case, sorry for this comment).

falcon03, jQuery UI 1.10 is compatible with jQuery 1.6+.

droplet, what comment do you suggest?

@falcon03 : jQuery != jQuery UI

@rootatwc, @jessebeach: thanks!

I misunderstood as I was suspecting. I didn't notice the missing "UI" suffix :-)

I'd really like to get this committed so we have more time to address non-obvious fallout.

Hm. Last time I blindly updated a version of one of our libraries, we completely busted a major front-end-facing feature: #1960612: jQuery UI 1.10 update broke Create.js, and thus in-place editing

This time, I'd really like someone to confirm that they've run http://drupal.org/project/fat and/or clicked around on various things (edit module, views UI, toolbar, etc.) to make sure we don't make that mistake again.

Link to a manual testing plan for Drupal 8 at http://drupal.org/node/1777342

I assume we're talking about 1799594-JS-improved-23.patch rather than 1799594-jquery-1.9-23.patch.

It seemed to work in SimplyTest.me and it seems to work, but ran into this error after developing some content with Devel:

InvalidArgumentException: Property uuid is unknown. in Drupal\image\Type\ImageItem->setValue() (line 101 of core/modules/image/lib/Drupal/image/Type/ImageItem.php).

Great to see the manual testing plan laid out so well. Thanks for the link.

Applying Patch Comment #23

Tested on Mozilla Version: 11.0

I have done part of the testing, based on link at comment #33, hopeful to complete the same in the next couple of days. I have also updated the manual test cases at: http://drupal.org/node/1777342

Please note that there was no new issue because of this patch(comment #23), so categorized into 2 baskets:
A) Functionalities that did not work Before & After applying patch
B) Functionalities that worked Before & After applying patch

A) Functionalities that did not work Before & After applying Patch

Need to identify if there is an associated issue already filed for the following issues.

SYSTEM
(admin/config/regional/date-time/formats/add, as user 1): Verify that the ajax preview of the date format is displayed and updated on keypress.
VIEWS
Views UI filter checkboxes: Create a node view, add a filter for type. Check that using 'select all' check all types, then test that unchecking a type also unchecks the 'select all' option, now check all nodetypes again, select all doesnot get enabled.
drupal.js - announce()
On /node/1 as User 1: Assert that clicking on the toolbar menu link tab (#toolbar-tab-toolbar-tray) places the text "toolbar-tray tray opened" in #toolbar-messages not in #drupal-live-announce element.
On Toggle: Children Menu(Content, Structure, Appearance, People, Extend, Configuration..) will hide: the text "toolbar-tray tray opened" still remaining in the DOM
I think because of Page not loading.

B) Functionalities that worked fine Before & After applying Patch

CONTEXTUAL LINKS
(home page, as user 1): Verify that hovering over the search block results in an outline w/ a gear icon.
(home page, as user 1): Verify that clicking the gear icon shows a drop-down to Configure block.
SYSTEM
(admin/config/development/performance, as user 1): Verify that checkbox to cache page for anonymous users show the "compress cached page" checkbox.
FIELD UI
admin/structure/types/manage/article/display/teaser: Verify that dragging a field (with mouse or keyboard) under the Hidden row changes the select value for this field to hidden.
OVERLAY
(home page, as user 1): Verify that clicking 'Configure block' fires up the Overlay.
(home page, as user 1): Verify that clicking X on overlay closes it.
VIEWS
Views UI filter checkboxes: Create a node view, add a filter for type. Check that using 'select all' check all types, then test that unchecking a type also unchecks the 'select all' option.
tableresponsive.js
On /admin/content as User 1: Assert that at a screen size of 400px or less, the th.priority-low elements have a style property display value of hidden.
On /admin/content as User 1: Assert that at a screen size of 400px or less, the element .tableresponsive-toggle exists and has a style display property value of block. (display: inline instead of display:block)
On /admin/content as User 1 Assert that at a screen size of 400px or less, the element .tableresponsive-toggle exists when clicked, causes th.helpful and th.advisable column headers to toggle from a style display property value of none to a style display property value of block or table-cell.

#35: awesome work!

I've confirmed that Edit + CKEditor also continue to work well. Both are now in the manual test plan too: http://drupal.org/node/1777342/revisions/view/2640282/2640342.

There is only one small problem with the current patches: they don't update library versions in system.module. Fixed in reroll. Otherwise I agree this is RTBC.

(In the reroll, 1799594-JS-improved-37.patch is identical to 1799594-JS-improved-23.patch from #23, I just reuploaded the exact same file, I only renamed it.)

drupal.js - announce()
On /node/1 as User 1: Assert that clicking on the toolbar menu link tab (#toolbar-tab-toolbar-tray) places the text "toolbar-tray tray opened" in #toolbar-messages not in #drupal-live-announce element.
On Toggle: Children Menu(Content, Structure, Appearance, People, Extend, Configuration..) will hide: the text "toolbar-tray tray opened" still remaining in the DOM
I think because of Page not loading.

The tests for Drupal.announce listed in the manual testing plan are outdated. I've removed this entry. We have tests in the FAT module now. http://drupal.org/project/fat.

SYSTEM
(admin/config/regional/date-time/formats/add, as user 1): Verify that the ajax preview of the date format is displayed and updated on keypress.

I logged a bug for this. It's not related to jQuery. It's a menu routing issue. #1965856: Form API AJAX request to get a date-time format example string fails to return correct string to Drupal.AJAX

#34, the devel issue is real but unrelated to the jQuery update.

I've run the FAT tests (coverage isn't complete, but there are tests there) and everything ran as expected.

We've also gone through the upgrade guide for jQuery 1.9: http://jquery.com/upgrade-guide/1.9/

I feel good about this update.

Woohoo! Thanks for the triple-check. Awesome work, folks. That's some EPIC testing there, sarav.din33! :D

I was a bit turned around by the two patches, but jessebeach told me to just commit both of them, so did that.

Committed and pushed to 8.x.

This will need a change notice.

Would be good to open a follow-up to un-patch jQuery bbq once it's fixed upstream as well.

As I understand it, jQuery 1.9 was an API step towards a jQuery 2.0, which will drop support for "oldIE" (6,7,8) and be smaller and performance optimized for browsers which are more modern. All good things for the future of jQuery.

With Drupal 8, supporting IE8, I guess suppose D8 will ship with jQuery 1.9 and never upgrade, except for minor releases. As moving up to jQuery 2.0 would require dropping support for IE8 from core. Is this correct thinking? Or are there some plans I'm un-aware of?

The upgrade to jQ 1.9 is good long term, as contrib will be forced to write code more compatible with jQ 2.0 and jquery_update could then provide jQ 2.0.

Just curious as I'm unclear with the direction of all this.

Yes - jQuery 1.9 and 2.0 will have the same API. 2.0 will be smaller and faster, but not support oldIE.

drupal_add_js() can now specify different js for different browser versions, so we will be able to ship D8 with jQuery 1.9 and 2.0 and the browser will automatically pull in the correct version.

See #865536: drupal_add_js() is missing the 'browsers' option.

Can we get a follow-up for #40?

follow-up issue. Hope makes sense:
#1972160: follow-up: update to jQuery 1.9 version

Next point is jQuery 2.0:
http://blog.jquery.com/2013/04/18/jquery-2-0-released/

Fix tags

+ bring the title in line for the change record.