Convert custom CSS/JavaScript to browser extensions?

[ProfessorBeyrer]

In my district we have ongoing discussions about how much to customize our CSS and JavaScript. Some of us have concerns about the risk of breaking the user interface when Canvas code is updated. On the other hand, the user of browser extensions like Greasemonkey and Tampermonkey allow some of those cool add-ons by the awesome Canvas developer community to be used.

My question is if there is an easy way to convert customized JavaScript or CSS into a script for a browser extension. The comments in the discussion TamperMonkey-GreaseMonkey-Postman Tutorial offer a sobering assessment of the future of CSS and JavaScript customization, so it would be great if there is a way to take those same features (like Improve Threaded Discussions with CSS) and add those to a browser extension that any user can access instead of asking our hardworking sysadmins to add custom script maintenance to their task list.

While I understand the benefit of saving non-developer users from having to do things like install browser extensions, I also like how empowered they feel when they realize they have more control over their Canvas experience.

[James]

I haven't tried browser extensions, but early on there was someone who took one of my scripts and incorporated it with some other tools they had.

ISOM Canvas Tools - Chrome Web Store 

GitHub - ron-t/ISOM-Canvas-Tools: Provides extra functions on University of Auckland's Canvas enviro... 

[lorewap3]

I can't say I've done this before, more often the case is I'm running javascript in tampermonkey for testing purposes and once I feel it's ready I move it into the canvas interface. 

But honestly I think it should almost be as easy as creating a tampermonkey userscript and copy/pasting the code into it. You have to set up the userscript in tampermonkey to only load for specific url matches (*.instructure.com/*/*) so it doesn't run on every page you go to, but after that it should work the same.

I think most of the issues arise from the order of loading. I can't say for sure, but I believe tampermonkey runs the userscript for a site after the site has finished loading. If it doesn't, you can always force it to wait for the page to finish loading via 

$(document).ready(function {

// code

});

If you have a bunch of different userscripts you want to load for a site, that's where it can get tricky. You have to make sure that they load in the right order if some scripts reference other scripts. You deal with this ALOT in normal web development, especially loading multiple js files into canvas. Javascript runs as soon as it's downloaded by the browser. So there's never a fixed order unless you force it to be that way.

What I really like doing is this:

// canvas_api.js $.getScript('<url to script>', function() {      // insert instructor button      $.getScript('<url to script>', function() {           //script is loaded and executed put your dependent JS here      }); });

Here I put any js dependent on the canvas_api.js to be loaded first inside. This loads those files only after canvas_api.js has been ran. 

A script in tampermonkey will fail if it uses jquery or any of those libraries and you don't make sure those libraries are loaded before the tampermonkey script runs (but won't always fail if just by random chance it's loaded afterwards). 

I know this is a little long winded of an answer, but I hope this helps.

[kedmison]

I tried this, with the idea of creating a "store" of browser extensions that users could choose from. There was some coding peculiarities for the extensions, but they were not showstoppers. 

But, for what its worth, we went the other way and decided to manage these scripts/changes centrally. Between the different levels of user experience, different browser and platform combinations, and the number of users we have, it became clear that this model was not going to be sustainable for us. We don't have a "you must use this browser" mandate, so we would have had to support extensions for all browsers. Also, we had some concerns from our Accessibility Lab about the behavior of the extensions. From a support perspective, we would spend much more time on end user support than we would ever spend in admin time keeping the scripts updated centrally. Plus, we had the issue of keeping track of user-level vs admin-level scripts.

We wrote a tool to bootstrap JS "plug-ins" centrally, based on user role and the page being loaded. For instructors, we provide a grade download extension that exports a file in the format needed for our SIS. The JS file that does that work and modifies the UI only loads on the grade book page and only for instructors and admins. I know that we will have to "fix" our extensions as Canvas starts to rely on ReactJS more, but this has been the approach for us that has worked the best so far.