Who can figure out why Stylesheet is blocked?

[Jeff_Mash]

Hey guys! This is probably simple to figure out, but my tiny brain isn't able to do it alone!

On a certain page of our site, we are seeing the following error when we debug the page using Firefox-->Inspect Element-->Debugger:

Blocked loading mixed active content “http://www.mjmmagic.com/store/includ...tylesheet.css”

Screenshot: https://i.postimg.cc/Xv23mGPs/screenshot-825.png

I am trying to figure out why that is.

How to reproduce:

1. Go to our website at https://www.mjmmagic.com/store/index...ain_page=login
2. Login using the following test account:
- Email: [email protected]
- Password: testing
3. Then go here: https://www.mjmmagic.com/store/page_2.html

When I go to that "page_2.html" page, that is when I am seeing the error in my debugger.

Every page on our site is running over an HTTPS connection. On this page, we are loading an IFRAME object, but the source is also HTTPS, so that shouldn't be a problem.

However, the error is referencing our Stylesheet.css file, but when you look at the PAGE SOURCE, you should see that none of our CSS files are running over an unsecured http:// connection. And nothing INSIDE of our stylesheet.css seems to reference any http: connection.

The reason why I'm looking into this is occasionally, I get a customer who has some issues on this page and we're trying to look at all possible issues. That is when I saw this error in the debugger and thought it might be related to something.

[Jeff_Mash]

I am suspecting this is directly related to the IFRAME even though the source of the iFRAME is an https:// connection. But the solution I found online simply says, "To fix this type of error, all requests to HTTP content should be removed and replaced with content served over HTTPS. "

Do you see anything in the source of that page which would indicate anything insecure that should be changed? Despite a couple of URL's to our social media which are HTTP, I don't see anything else.

[Jeff_Mash]

Nevermind......figured it out! The third party site who we are loading into the IFRAME was referencing our CSS file on their end (which then carried over to that error on our end). I was busy securing the IFRAME SRC parameter (making sure it was https), but failed to notice that the contect which loaded after that connection was referencing an insecure CSS file.

So apparently my tiny brain didn't let me down. Case closed!