Catalog customizations sporadically not loading?

[mrash2]

My institution's Canvas Catalog environment has some custom CSS and JS at the main/root catalog level. We're still using jQuery but not using anything deprecated, thus it is compatible with 3.7.1. This morning, we're noticing the script is not executing, and the issue is sporadic. Sometimes it loads normally upon a hard refresh in the browser, other times not at all. No error message are displayed in the browser or console.

We have not made any changes to the customizations, but multiple users are encountering this intermittent strange behavior.

Anyone else experiencing anything like this?

I'm already looking at switching to vanilla JavaScript for our customizations, but can confirm things work as they are - when the script actually executes, that is.

[Paola_Sanchez]

We are also experiencing the same behavior.

[kgrage]

We're experiencing the same issue with the custom JS not loading consistently (CSS seems to be loading fine). It seems to be browser and device independent (tried Firefox and Chrome in Windows and Mac; cleared cache, restarted browsers, etc.).

[eric_silva]

Yes, we're also seeing the same inconsistencies as well. 

[TamiSnyder-Knut]

Yes, we are experiencing this, too. Has anyone managed to find any information or get support on how to resolve the issue? I have a support incident in progress, but we've been having this issue all week now and it's starting to impact more users.

[SenskyMoe]

We just posted a Tier 2 support ticket so I am hoping to get some traction today. It seems everyone experiencing the issue has custom code (CSS and/or JS) in Catalog - would you say that is correct? We do for sure.

[mrash2]

Yes, we also have custom css & js. We have opened a support case as well.

[SenskyMoe]

Same issues here!

[SenskyMoe]

@jperkins could this have anything to do with deprecating of jQuery or similar for security concerns? Wondering as I found another blogpost from you Updating jQuery in Canvas - Instructure Community - 596684

[mrash2]

We're not using any deprecated jQuery in our instance (i.e., nothing that would require JQMIGRATE). 

[mrash2]

Update: I also just rewrote our script to not rely on jQuery (something we've wanted to do for a while anyway), and it is facing the same issue: it only wants to execute upon a hard refresh. To me, it seems like a caching- and/or MIME-related issue with Cloudflare, which appears to be where that custom code gets served from.

[mrash2 · Accepted solution]

UPDATE: We received a response from a Level 2 support contact. At least in our situation, on the times when the custom js did not execute, it appeared that none of it ran. However, it turns out that portions of the script indeed did run every time. Thus, the problem had to do with how items on the page are rendered in the browser. If you're using jQuery, it's not enough to wrap your code in a document.ready() block. Instead, you'll need to make sure any page element you are manipulating or referencing with your script is fully present on the page. A helper function (for example, onElementRendered) should help with this. Since our code has been working problem-free for several years, I'm not sure if something changed in the Catalog codebase and/or the way browsers render the DOM, but the change was significant enough to start causing this new issue.

In our situation, we've also been looking to move away from jQuery in our custom script, so we took this opportunity to do that as well. Upon first simply converting our existing script to vanilla JavaScript, we experienced the same inconsistent behavior. However, once we updated the vanilla script to always check for an element to be rendered before attempting to manipulate it, things seem to be working properly.

We're still double-checking things before closing our case with Instructure, but I wanted to share an update here for those still investigating your own instance.

Bottom line: be sure your code checks to see if a page element is rendered before attempting to reference or manipulate said element.

[zowada-a]

I am really not sure how to check this - do you have a sample of code for how to force the element rendering?  I'd be happy to provide the code I'm using if it helps!  I didn't set ours up, but it worked wonderfully until last week, and now we have a real mess.

[mrash2]

Here is a basic function that can be used to make sure an element is rendered:

// Helper function to wait for elements to appear
function onElementRendered(selector, callback, attempts = 0) {
  const els = document.querySelectorAll(selector);
  if (els.length) return callback(els);
  if (attempts >= 60) return;
  setTimeout(() => onElementRendered(selector, callback, attempts + 1), 250);
}

You can then call this function whenever you need to reference or manipulate an element. For example, we edit the text of the Login link in the header like so:

// Header menu updates
onElementRendered("#header-menu > #header-menu-container > div > a:first-child", ([el]) => {
  el.textContent = "Login or Create Guest Account";
});

[zowada-a]

Great - thank you!!  I will give this a try and see if I can get it to work.

[SenskyMoe]

Hi, you write "Since our code has been working problem-free for several years, I'm not sure if something changed in the Catalog codebase and/or the way browsers render the DOM, but the change was significant enough to start causing this new issue." - we realized this is the issue and that's how we fixed it but I am trying to get L2 to respond to what they changed for this to happen/become a problem. Do you have any clear messages from L2 on what changes Instructure has made?

[mrash2]

Unfortunately, no, we don't have any information as to what changed on their end.

[KathyPalm]

@SenskyMoe and I received some additional information from L2 about a backend change which is likely  the cause:

"Our engineers have let me know that there was not a change to the code that was made in the Catalog deploys around when you reached out to us regarding the reported behavior, however, there were translation changes in that deploy.

They said that we cache translation files in a CDN and when there were changes made in those translation files, whenever someone tried to access them over HTTP instead of HTTPS, this was causing the wrong file to be cached, so other users in that same region would receive the incorrect file from the CDN when accessing their Catalog page. Our engineers have put a fix in place to now redirect HTTP requests to HTTPS instead of serving that cached file, so the issue should not occur again."

[SenskyMoe]

We tried the same with success! Still keeping the ticket open with Instructure though to find out/understand what happened on their end. Thanks for the dialogue! @mrash2