Showing results for 
Show  only  | Search instead for 
Did you mean: 
Community Participant

Targeting the iFrame using Javascript in the new UI

Jump to solution


I've been using this very important piece of javascript in my custom javascript file:

var iFrame ='window_content');


It is not working when the new UI is enacted. I'm guessing it might have something to do with the ID of the iFrame in the new UI but I cannot figure it out.

I have uploaded the Javascript file via the Theme Editor

Please help!

Best ,


Tags (2)
39 Replies
Community Champion

There is not. See the list of allowed tags for the Rich Content Editor. The list of allowed attributes for the iframe tag are on the first page.

You would think that adding something like that into the allowed list would be fairly easy, but I spent about 3 hours one day with one of the Instructure engineers trying to fix the editor so that it would not remove empty <i> tags and he spent several hours beyond that and we were never able to get it to work. Granted that particular issue was fixed when they updated the editor a few months back, but the issue is make changes to the editor are not as easy as you would think.

That's a nice resource James, thanks for sharing.

Community Participant


Can I tell you what is happening now and you may be able to shed light on what is going wrong.

I updated my javascript file with your code (thank you!) and uploaded the file via the Theme Editor.

Now, when I load the page the very first time (on iOS) the changes are taking effect. When I reload the page or go to another page with the same iFrame ID the javascript is not taking effect.

Occasionally when I reset Safari the code will work but it seems quite random.

Lastly, for a number of reasons I need to put my iframe in a div. You can see that below. Is this causing some kind of problem?

<div style="position: relative; padding-bottom: 50.25%; padding-top: 15px; height: 0; overflow: hidden;"><iframe id="window_content" style="position: absolute; top: 0; left: 0; width: 1px; min-width: 100%;" src="" width="300" height="100%" name="window_content"></iframe></div>



Okay, new update. I just noticed the following statement from w3schools "The <iframe> scrolling attribute is not supported in HTML5. Use CSS instead.". All of the browsers that Canvas supports (Which browsers does Canvas support?​) support HTML5. I did some searching and found a post on Stack Overflow (HTML5 : Iframe No scrolling?​) that suggests the CSS "overflow:hidden;" achieves the same thing. I try to avoid iframes whenever possible so I am not sure how close the 2 are, but it is worth trying.

I am not sure what the cause of that would be. The <div> shouldn't have anything to do with it. I will need to do some testing with iOS to see if I can figure it out. Are you just using a browser on iOS or are you using the app? Also see my post below for a possible CSS solution.

Community Participant

I tried overflow:hidden; but that didn't work for some reason.

It is now working however. I realized that I still had the old javascript code in active in my file. Once I commented it out your code started working!

Thank you!

And the fact that it's not supported in HTML5 may be why Canvas doesn't add it. There are a whole bunch of reasons why something may not get added that people want added. I've written about it before, I think the last time was Re: Unfortunate Audio Icon Needs Replacing  back on Oct 9. Things that we think are simple may not be that simple when you delve into it. Canvas also needs to make sure that whatever they do works in multiple browsers, multiple devices, etc., so scrolling may work for someone using HTML4 but not HTML5. It might work in MSIE but not Firefox. I found something the other day that was deprecated in HTML5 but still supported by everybody but Firefox. I'm sure that Canvas does a lot more testing than any of us are able to do with our scripts. That's part of the argument of why it should be hard for people to add scripts to a page.

But I am definitely with you on iframes. I try to avoid them like the plague in anything I write.

 @kenneth_larsen ​,  you have pull with Canvas so they were willing to spend that time looking at your issues with the editor. The rest of us have to suffer through bad or misconfigured TinyMCE plugins.

I would be much happier if the Rich Content Editor generated valid HTML. Beyond the first rule of accessibility being to generate valid HTML, I am writing a Google Sheet application to analyze a discussion and wanted to parse the HTML in a discussion to pick provide a plain text summary and so it was readable instead of having to read through HTML to find what people had written. Google Sheets has a parser, but if barfed a few posts in when it reached invalid HTML. I ended up doing a machete approach of just removing all tags.

Interesting, I have never really encountered places where the editor created invalid HTML, just the editor being a little overzealous in it's cleanup. Do you have any examples? I would be really interested in trying to figure out a way to identify and correct those types of issues.