Can you post a link to a publicly accessible page (i.e. no authentication or signing on required)?

Are you using HTTPS-Only ? Does it help if you disable HTTPS-Only for this website ?

• https://support.mozilla.org/en-US/kb/https-only-prefs

You can check the Web Console (Tools -> Web Developer) for messages about blocked content and about the presence of mixed or unsafe content.

• https://developer.mozilla.org/en-US/docs/Tools/Web_Console

You can check the Network Monitor to see if content is blocked or otherwise fails to load.

• https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor

If necessary use "Ctrl+F5" or "Ctrl+Shift+R" (Mac: Command+Shift+R) to reload the page and bypass the cache to generate a fresh log.

Hallo, this is a Link: http://skybird.dominohosting.biz/skybird/SKYBIRDDev.nsf/$$OpenDominoDocument.xsp?documentId=6EE025D65A9337BF002587220042117C&action=openDocument

To reproduce the problem: Click "outline" in the grey bar. It will open an outline navigator. Click "VEB IL-14P" to open a page containing the iframe.

The area below will be empty or will show the intended content - alternating. When you repeat the two clicks, so it will switch to https and show the empty area and next time it will switch to http and show the intended content.

I don't use "Only HTTPS Mode". I use "Don't use only HTTPS mode".

If you need more information, so we could do a teamviewer session.

I can see that there is some difference in how the response from the opendocument from the hosting server (domino server most likely) is shifting the URLs from HTTP to HTTPS.

When the URL is HTTPS like this, I see the below error response on the web-console

Blocked loading mixed active content http://skybird.dominohosting.biz/il14/il14photo1-d.htm

And after this error shows up and then I click the VEB-14P link, I see that the URL is shifted to a HTTP one. And there are no error messages in the web-console.

Any time the connection upgrades to HTTPS is when there are no images shown in the iFrame. And trying it the second time, the connection switches back to HTTP and the images in the iFrame are loaded.

To check further, I checked the iFrame URL and that seems to load fine in HTTPS.

So there could be two things that might be happening - either FF is upgrading the connection to HTTPS even though always HTTPS-ON is turned off or the server is switching the URLs to HTTPS which might be causing the connection blocks.

Is it possible for you to check the server logs while we try to figure out if Firefox is upgrading the connections to HTTPS.

Thank You

This is a problem with the website. They explicitly use the http:// protocol to load content in an iframe, so if you load the main page via http:// then it work, otherwise Firefox will block the iframe. You can see this as an error message in the Web Console.

• https://developer.mozilla.org/en-US/docs/Tools/Web_Console

If you edit the URL and leave out the protocol (http:) leaving only the //skybird.dominohosting.biz part then Firefox automatically use the same protocol as used by the main page and then it works in both cases.

Continuing on the above message from cor-el, if I modified the iFrame URL to *not* have the protocol and leave it as a relative URL, then the page loads fine without any errors. If you can please ask the website provider to make this change, it should resolve your issue.

Thank You

Hallo Gnittala, thank you for having a mindful look to my problem and accepting it as real. I looked also into the HTML sources (using Firefox menu function) of the both kind of pages, the empty (https) and the filled (http). I saw: the iframe call and the link to the content were identically and with explicitely http. I cannot believe, that the server causes the switch between http and https - all the other browsers don't have this problem - and I think, that the answer of a server to a http GET doesn't depend of the kind of requester - an identical request should give an identical answer. The server is a DOMINO server with shared use for several domains. I don't have direct access to the servers log, but I will ask providers support to give me some information. Neverthless - I think, that Firefox is doing this switching. I'm hoping for your help. Martin

Firefox might be forcing a secure connection like when you have enabled HTTPS-Only mode or use an extension like HTTPS Everywhere.

• https://support.mozilla.org/en-US/kb/https-only-prefs

Since this website forces the HTTP protocol for loading the page in the iframe, this only works if you use the HTTP protocol and not with the HTTPS protocol as Firefox doesn't allow framing an insecure webpage. This page obviously got created when HTTP was common and hasn't been adopted and tested to work with HTTPS although there is a valid certificate installed.

<iframe allowfullscreen="true" sandbox="allow-same-origin" src="http://skybird.dominohosting.biz/il14/4------d.htm" width="100%" height="1000em"></iframe>

If they changed the source attribute to leave out the http: then this works in both cases as browsers automatically use the same protocol as for loading the link.

• http://skybird.dominohosting.biz/skybird/SKYBIRDDev.nsf/$$OpenDominoDocument.xsp?documentId=6EE025D65A9337BF002587220042117C&action=openDocument

<iframe allowfullscreen="true" sandbox="allow-same-origin" src="//skybird.dominohosting.biz/il14/4------d.htm" width="100%" height="1000em"></iframe>

Thank you for your effort. I changed the link in the iframe to a relative URL: <iframe allowfullscreen="true" height="1000em" sandbox="allow-same-origin" src="/il14/4------d.htm" width="100%"></iframe> This solved my problem.