Showing results for 
Search instead for 
Did you mean: 
Community Member

Deprecated use of magic jQueryUI widget

Jump to solution

Hello All,

I just got this message in my web inspector:

'You're relying on undocumented functionality where Canvas makes jQueryUI widgets out of rich content that has the following class names: .dialogue, .draggable, .resizable, .sortable, .accordion, .tabs.

Canvas is moving away from jQueryUI for our own widgets and this behavior will go away. Rather than relying on the internals of Canvas's JavaScript, you should use your own custom JS file to do any such customizations.'

I am really just wondering if anybody knows what is going on because our style guide has not yet been updated to reflect this change. We are using accordions in many places and if Canvas deprecates this functionality is going to break a lot of our materials. Thus I want to get out in front of this as quickly as possible. It sounds like Canvas is going to be using their own widgets. Will we still have access to those? If so when can we expect the style guide to be updated?

Any insight into this matter would be appreciated.

Thank you



A solution was found. Canvas suggests that institutions stop using Jquery UI and instead include their own custom code for such things.

1 Solution

Accepted Solutions

Hey everybody, this is Ryan Shaw, from the canvas engineering team. I see a lot of great questions here and some worry so I wanted to chime in to provide some guidance and assurance.

A little background: Canvas has, for a long time, used jqueryUI for our own widgets. So when you see a modal dialog pop up or an accordion or a group of tabs, they were probably using jQueryUI. One day, after talking with some awesome customers at instructurecon that were creating their own content, we decided to add this little piece of code: so that if you added class names like .tabs, or .accordion to your content it would automatically turn that element into that kind of jqueryUI widget for you without having to write any code yourself.

The problem:

First, sometimes the markup that gets created from people doing this in their content is not accessible. So, for example, users using a screenreader would not be able to use that content. That’s a huge bummer for them so we wanted to make sure we weren’t contributing to that.

Second, we are starting to rely on React.JS more and more in our front-end code, and we have even written our own UI library ( that is built on React and is much more modern, has better UX, fixes a ton of bugs that would pop up with jqueryUI widgets and, has some of the best accessibility support of any UI lib I’ve ever seen. So we have started replacing places we were using jQueryUI widgets to use instructure-ui widgets and using the latter exclusively for new code.

So eventually, we hope to get to a point where there is nothing that canvas is doing that is using jqueryUI and loading it will make canvas slower for everyone. jQueryUI is a big javascript library, and loading all of it's code on every page has a real cost in terms of time it takes to download and view every page. We don’t want to slow down all of canvas for everyone even if they are not using this.

That's why we put that warning message in there. And in general, it will be safer and less brittle for your custom interaction code to not be dependent on canvas’ code. So us making a change doesn’t break your code and vise-versa. That’s why we recommend loading your own widget library in your custom ThemeEditor JavaScript file if you want to add custom widgets to your content.

As far as when will canvas stop using jqueryUI anywhere, I’ll be the first to tell you that it will take a long measured in years, not months. And as long as we are loading jQueryUI widgets for something we need on the page, there’s no reason not to expose it like this for you to use too.

So the “official” future-proof, encouraged way of adding your own widgets is to include your own UI library in your custom JS file so it is not dependent on anything from canvas’ code. (On a side note, if you are going to do that, make sure that you are using a library that has good accessibility support, there are a lot out there that look nice but are unusable by screenreaders)

But, if you have a bunch of content relying on this and you are willing to stay on top of things, and check the release notes and react if canvas does stop using jqueryUI, you are free to do so, however it is now considered “unsupported”. But we will say something in the release notes if we ever do remove this feature, and in the worst case scenario you could just add jqueryUI to your custom ThemeEditor JavaScript file and a similar snippet to what we did for this and not have to change any of your content even after we stop supporting this.

I hope that helps clear up some of the what, why, and when behind this question. I love reading these forums, you guys are so innovative, so helpful to each other and your passion to create great educational content shows!

View solution in original post

28 Replies

Thanks for asking this!  I linked to this topic from a blog post with comments which mention the same jQueryUI libraries:


 @jnickerson1  Thank Youfor staying on top of this! Is this as catastrophic as it sounds? There was such interest in‌ that I think at this point there is probably a lot of content out there built off this framework. Is this something we should be sounding the alarm about more broadly? Do you think we should be trying to update all the community resources with this latest information? Do you think Canvas could do anything to help address this? I'm concerned but not 100% sure yet how concerned I should be...

It would be GREAT if Canvas continued to support this as a feature for users even if they are not using the scripts themselves, but I guess maybe that too much overhead for them. I was really excited about using this more, but now I am hesitant since I'm not sure if I would have any support at my school for installing and maintaining the script support locally.

I would say it is possible that for some institutions and some teachers this is going to be fairly catastrophic. I am not affiliated with canvas, so I cannot speak on their behalf. However, when I first discovered this, to say I was alarmed would be an understatement because we were using these widgets a lot in our materials.

I do personally believe it is something that Instructure should be sounding the alarm about more broadly. I am somewhat surprised that they are not giving people more warning. Indeed the current warning is quite subtle and if you're not staring at your console all the time it could easily be missed.

After discussing this on the phone with some Canvas representatives they confirmed they are deprecating. They did not offer a timeframe but did say it would be a while yet (I don't know if that means months? years?). But it was decided that the best course of action would be for us to redo our courses using our own scripts. Lucky for us, our organization hasn't been using Canvas very long so we were able to quickly go back and redo all of our materials.

The positive side of this is that, IMO, the "widgets" that I built myself actually function better and are more performant than the jQuery UI "widgets". We also have more control over how they behave and how they are styled now. So although it was a little more work upfront, we are actually much happier with the end result.

I should mention that I do find it peculiar that Canvas is still showing these on every institution's style guide. In fact I find it peculiar that they even have these style guides associated with each institution. The reason I feel this way is that when I asked them about it during one of our phone conversations the response was that the style guide is only for Canvas developers, not for content creators. So it remains a mystery why they would even have an institution level style guide if it is not meant to be used.

Although I do find the style guide useful because we still take advantage of other things that are NOT being deprecated such as the Flexbox Grid.

Community Team
Community Team

Hi, all,

Information about this change was posted in the 2017-02-18 Canvas Production Release Notes

Hope that helps!


Thank you, erinhallmark‌! Can we get a translation for us mere mortals? One of the reasons the tabs and accordions are so nice is that we don't have to be sysadmins or programmers to use them. I'm not sure what this means:

Canvas engineers have already coded a temporary adjustment for these functions without requiring any immediate changes, though the adjustment will log a deprecation warning to the browser’s console and include information about how to correctly adjust the JavaScript moving forward. For concerns about jQuery loading, admins should use the global $ variable that will be loaded before the script. 

I'm about to embark on a content development project for Fall (I just started it this weekend in fact), and it sounds like I probably should not use the tabs and accordions unless I can get my Canvas admin to do something, but I don't know what I would ask him to do (and I'm hesitant also... this is not the kind of support request they probably want to get...). Any additional information would be much appreciated  — thank you!

Thanks for keeping an eye out Erin. However, the switch from RequireJS to Webpack is unrelated to this discussion.

Although a common misconception, jQuery is not the same thing as jQuery UI.

To clarify: Canvas will continue to use jQuery (considered a necessity). Canvas will not continue to use jQuery UI (not considered a necessity).

To make light of this, please enjoy this humorous (humorous because its true) article poking fun at how confusing it is for a new developer to learn the modern world of JavaScript (not to be confused with Java - they are entirely unrelated). It is probably safe to say that nearly every developer experiences pain/despair from this early in their career.