New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 84 users
Status: Fixed
Closed: Apr 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment
Load unsafe scripts functionality does not load mixed content in iframes in Version 48.0.2564.97 m
Reported by, Jan 29 2016 Back to list
Chrome Version       : Version 48.0.2564.97 m

What steps will reproduce the problem?
1.Launched my application which had unsafe scripts
2.Clicking on the load unsafe scripts shield broke the application and loaded blank page instead of the actual content.
3. This started happening on 48.0.2564.82 (and up, i.e. 48.0.2564.97 m)

What is the expected result?
the page loads all unsafe scripts and renders the content

What happens instead?
Only the first insecure https request gets loaded the rest are blocked.
Blank grey page is loaded and the console shows the following errors:-
This request has been blocked; the content must be served over HTTPS.  something.html:1 Mixed Content: The page at 'http://something' was loaded over HTTPS, but requested an insecure script

Please provide any additional information below. Attach a screenshot if

This used to work in versions prior to 48 of chrome.
It is a major blocking issue as our customers are unable to use our website.
I can confirm this, it seems this is was patched in on chromium a bit ago, and it has finally made its way to stable users. I have checked all versions in dev and canary and they all do the same thing.

Clicking the shield loads the "first layer"

If you have an iframe within an iframe, the shield does nothing, the first iframe passes through, but nothing past that. 

Would be nice to know if this is on purpose or if this is really a bug?
Hmm...I have seen it not work for the first layer either...Maybe it is a bug?
Comment 3 Deleted
Noticed this myself and could come up with a test case.
Two script HTTP tags, shield shows and works for both:
A script tag and a script tag within an iframe, shield only works for the host page script not the iframe:
Labels: Needs-Feedback
@hsaini: Could you please provide us the sample file along with the screen-recording explaining the issue, would help us in triaging it further.

Thank you.
I am providing a sample file, but no screen recording as I can't do that right now. Hopefully my details can shed some light.

upload iframetest.html into a webserver that allows https, or else you wont be able to see the problem, obviously.

I gathered some websites that work in iframes for this test.

1. Open iframetest.html in a normal tab, without https, so you can see how the page would render. 

2. Open iframetest.html in a second tab, with https, and you will notice the options for the shield (normal behavior);

3. Click the shield icon to allow "load unsafe scripts" and let the page reload

4. Notice pages rendered poorly as some content is being blocked still even though "load unsafe scripts" was clicked on. 

A few things I have noticed as patterns from these pages:

Example: loading

'Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure image ''. This content should also be served over HTTPS.'
  ------ Most pictures seem to work, either jpg,png,svg, etc. Even if the domain is different. (it calls for the images on


'Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure stylesheet ''. This request has been blocked; the content must be served over HTTPS.' 

'Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure script ''. This request has been blocked; the content must be served over HTTPS.'

  ------ If its is CSS or JS on a different domain, the content gets blocked. 
444 bytes View Download
I can also confirm that it also blocks content that is JS/CSS even it is on the same domain. 
Can confirm the issue here.  My case was that the sites in iframe can load but all the resources it needs(JS, CSS etc) are not loading. The error message was "This request has been blocked; the content must be served over HTTPS".
@hsaini: Attached is the output we are observing, please provide us the screen-recording for better understanding of this issue.

Thank you.
Screen Shot 2016-02-02 at 11.53.10 AM.png
438 KB View Download
@rnimmagadda: I believe you need to serve the file from HTTPS to replicate the issue.
In my experience, to recreate the issue, you need to be on an HTTPS site that is attempting to load scripts/css from within an iFrame where the scripts/css source from HTTP.
@rnimmagadda: Like I stated in my instructions, you have to upload the file to a webserver that has HTTPS available, or else you will never see the problem.

http will load the page normally, and that's how it's supposed to look like once you go to https and click on the shield icon and click "load unsafe scripts".

Attached is chrome 47 with https. Page loads normally.

Second attached is chrome 48+ with https. Page loads messed up.
IFRAME - SHIELD TEST - Issue 582603 - Chromium.jpg
140 KB View Download
IFRAME - SHIELD TEST - Issue 582603 - Google Chrome.jpg
170 KB View Download
Here are some logs aswell. I changed it so I would only load one page so you can see consistency for one domain.

First attached is Chrome 47

Second is Chrome 48+.

I have noticed by looking at the logs, chrome 47 requests the files differently then chrome 48+.

In chrome 47, requests look like so:

Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure script ''. This content should also be served over HTTPS.

In chrome 48+ the output is completely different, even though it requests the same file, and nothing is changed at all:

Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure script ''. This request has been blocked; the content must be served over HTTPS.

So JS/CSS right now we know is blocked, any image type file, is allowed.
Requests have changed also, as they all say:

"the page at '' was loaded over HTTPS" (or whatever the your domain/page is).

While they used to say:

The page at '' was loaded over HTTPS (or whatever the domain/page is).

Chrome 48 - Issue 582603.log
3.5 KB View Download
Chrome 47 - Issue 582603.log
20.9 KB View Download
I notice the exact same issue on my hand (using Google's API explorer with a local Google Endpoints API). Up to Chrome 47, clicking on the shield reloaded everything and loaded the local APIs, with Chrome 48 only the first layer with mixed content is loaded but the rest of them still give an error.
experiencing same issue. What addtl info does Google require before they assign to and engineer?

loaded over HTTPS, but requested an insecure script ''. This request has been blocked; the content must be served over HTTPS. Uncaught ReferenceError: $ is not defined Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure resource ''. This content should also be served over HTTPS.
I'm experiencing the same issue with the API Explorer as the user in comment #14.
This is a very prominent issue and affecting lots of Chrome users. It would be really nice to know if this is a bug or done purposefully. Can we expect this to be fixed as hotfix in chrome v49 which is still in beta right now.
Labels: -Needs-Feedback TE-NeedsFurtherTriage
Could someone from Dev team please look into this issue.

Thank you.
Our web application allows our customers to edit content on their websites in a WYSIWYG way. Often these websites are only available through 'http'; as our application is only available through 'https', the editing feature doesn't work anymore in Chrome 48 as result of this issue.

A hotfix for v49 would be great!
While I agree that it is the web developers responsibility to protect users from malicious content, users should not feel the wrath of improperly communicated page delivery expectations from those in the know. am just sayin...
Similar issues in out webapp.  
Mixed Content: The page at 'https://site.withheld/Widgets/iframes/SomeApp_MapView.aspx' was loaded over HTTPS, but requested an insecure script ''. This request has been blocked; the content must be served over HTTPS.

We don't control the bing maps stream, nor is it trivial to rewrite using a different map source.  This is driving users to IE where the apps actually work after you accept the mixed content warning.  

Please restore the mixed-content "Load anyway" feature or provide a programmable settings update workaround.
Same here with the Google API Explorer and local API

FYI a possible workaround is to launch Chrome with the flag "--allow-running-insecure-content"
I have already tried launching Chrome with  flag
"--allow-running-insecure-content" but with No luck.
Tried on Mac, Linux & Windows but it ultimately drills down to the same but
and starts blocking mixed content.
Comment 24 by, Feb 5 2016
Same issue here, it's failed to run unsafe script.
It's ok before Chrome v48, but now latest version 48.0.2564.103 m failed.
Also notice that now Chrome failed to render the shield icon, but just show plain text "Load unsafe script"
Is there a confirmation of the bug from Chrome?
Thugh there is a solution to pass --allow-running-insecure-content while starting browser via command line but this does not work for any iframe within page url.

Its causing a lot of trouble.
Labels: Cr-Internals-Network Hotlist-Enterprise
Labels: -Cr-Internals-Network Cr-Blink-SecurityFeature
This sounds like a mixed scripting, not networking issue.
Same here with the Google API Explorer and local API
We are ratcheting down on mixed content, and are intentionally making it more difficult to execute mixed script. We intend to show the shield less often, with the eventual goal of removing user-visible surface entirely.

That said, the command-line flag should still work at the moment. Emily, could you check whether any of your vaguely recent refactorings might be the underlying cause?
This bug completely breaks the default method for using Adobe Target, thankfully Adobe have a proxy system which can bypass this issue but it's not always the best method.
This was intentional as a step on the way to removing the mixed content shield all together:

The --allow-running-insecure-content flag does seem to still work for active mixed subresources inside iframes, though.
This breaks functionality for several web applications that allow users to edit/modify their own site through a WYSIWYG editor, tagging system, etc. Expecting those users to load using the --allow-running-insecure-content vs. sending them to another browser is silly, as is expecting developers to be able to control the markup of 3rd party sites that integrate with their applications. We need an easy to use, end-user-exposed way to opt into insecure scripts. 
Summary: Load unsafe scripts functionality does not load mixed content in iframes in Version 48.0.2564.97 m (was: Load unsafe scripts functionality broken in Version 48.0.2564.97 m)
The relevant counter (BlockableMixedContentInSubframeBlocked) doesn't show up on yet, I guess because it's not in stable yet? Based on data from beta, it looks to me like the BlockableMixedContentInSubframeBlocked counter fires on somewhere around 0.06% of page loads... which is low, but not under the deprecation threshold. What do you think, Mike?
Have you seen the new hint in the API Explorer and in the doc :

This seems to solve the problem without beeing a big fat security hole in our browsers
Comment 36 by, Feb 10 2016
Using the flag --unsafely-treat-insecure-origin-as-secure as suggested in #35 would only solve it if you know beforehand what site(s) you want to load with insecure content.

For the (very common) use case of web applications that want to manipulate -other- websites, for example creating A/B tests or personalization purposes (players like Optimizely, Adobe Target, BlueConic and hosts of others) you do not know beforehand what sites the users will use. Removing the 'load unsafe scripts' option totally breaks those applications. Please provide an API (for a chrome extension), UI option or anything else to bring back this functionality for this probably unintended (didnt see this usecase mentioned anywhere in the discussion in 2015) massive side effect of this change.
We are getting the same issue! when attempting to play an insecure flash Iframe it will no longer play since V48.
Comment 38 Deleted
Can anyone from Google verify that this is in fact a bug?
How should tools like APIs Explorer proceed in the face of the mixed content shield being removed? I don't know if the flag is officially supported or not, and as mentioned in #36, while it works for some use cases it fails for others.
Re #40: I don't think that relying on running active mixed content is a viable long-term strategy. Firefox is moving in this direction too: Chrome on Android and iOS also do not have a mixed content shield.

Does --allow-running-insecure-content work for your use case? I don't see any reason why that wouldn't work.
Re: #41

Long-term: I'll work on a solution path that eliminates the need for mixed-content.

Short-term: It does work for now. But how long can I rely on that flag being available? A month? A year?
Comment 43 by, Feb 18 2016
I would like to reiterate that this is not a solution for end-users who use a web-based application to manipulate or view their own site (for A/B testing, analytics, etc.) Asking a consumer to launch chrome with a flag is a non-starter.

It is one thing to ask the host site to manage their HTTPS well, it's another to completely break them when sites opt-in to being served via iFrame for a specific use-case, with no UI feature to give access for users that understand what and why they are doing. An example of this with a Google product is GA's "In-Page" analytics. 
Comment 44 by, Feb 18 2016
Re #41: To be clear; there is no 'other viable long term strategy' then to continu to rely on running active mixed content when a web application embeds another site in an iframe. The application does not have any control of that other website. If there is no API, GUI or flag it will totally break numerous applications, and end-users will be unable to visually adapt or inspect their website (as said above, for analytics, a/b tests, content mgmt).
Re #43 and #44: For some of the developers that I've talked to so far about this, popups can sometimes be decent alternatives to iframes when the framed content is only available over HTTP. Is that kind of solution a possibility for you? It might be a worse UX than iframes... but having to instruct users to click through the mixed content shield isn't such a great UX either. :)

Regardless of what we end up doing on this bug, I think it's really important to figure out how to not rely on active mixed content in the long term. It's only going to get harder/impossible: a.) browsers have already and are going to continue to diverge on the UI treatment, and b.) browsers will continue to make it harder and harder to find and use the shield, to avoid the risk of people being tricked into using it without understanding the security risks.
One of the circumstances in which we rely on active mixed content is when testing against localhost servers (where it's usually a lot simpler to use HTTP and ask the developer to click the shield than it is to ask them to set up and install multiple self-signed SSL certs). Popups aren't really a proper solution for our use-case as there is a need to be framing in dynamic/active content into the page and communicating with the parent frame.

However, I still think that this is a bug, if a user clicks on the shield, it will load a HTTP Iframe, but then not allow it to even load relative scripts coming from the same server. It doesn't really make sense to allow the frame itself not its subresources. Especially since if those subresources were in the same context as the parent frame it would load fine (after clicking the shield). There's no additional security risk there that I see, if they've clicked the shield.
Surely a compromise of a developer console setting or something could be agreed upon here to allow mixed content for the purposes of using Google Analytics in-page, Adobe Target, Optimizely to name but a few critical web optimisation products?
Re #46: I think for developers the command-line flag should be acceptable, right?

Re #47: yes, we've been discussing various possible futures, including a setting in developer tools. I think the question on the table at the moment is whether it's necessary to roll back (since moving the shield to dev tools is a longer-term project). There is some more discussion, including Firefox's plan, on the blink-dev thread I linked above (
Oh, also re #46: I'm thinking over what you said about subresources on HTTP iframes. It might make sense to only do the strict blocking if the frame itself is loaded over HTTPS.
 Issue 587116  has been merged into this issue.
Comment 51 by, Feb 25 2016
Re #42 In the long term, when a site loads all subresources correctly over https the problem is solved. Issue is of course that websites have so much subresources from all over the internet, it will take quite some time before they are all available in https. At this point in time lots of websites can be loaded using https, but almost all subresources are then loaded from http, unfortunately.

We discussed running the target website in a popup. Although technically possible, there is no easy way to show toolbars etc in the popup, it can mostly be used only for navigation. It breaks the UX as you mentioned and leads to a confusing experience for users. 'load unsafe scripts' isn't great UX either, but its a one thing only.

Re #47 it will probably alleviate the issue if strict checking is only available for https, although if a customer wants to edit/preview their (https) website instead of the http version in the iframe it would then still break.

Ideally I think you would like to have some kind of an 'advanced' setting somewhere, maybe even only for specific (top) URLs (* where mixed resource loading is allowed, and continue to move towards blocking active mixed content for all other users. This way, users of web optimization software have to do a 1 time setting/configuration (which might be a bit harder to find, but it is an advanced feature anyway), while the 'regular' users are not bothered with it.

Project Member Comment 52 by, Feb 26 2016
The following revision refers to this bug:

commit f9aced4a99289d153e4536affaa36618bb23dbd8
Author: estark <>
Date: Fri Feb 26 18:11:32 2016

Apply strict blocking of active mixed content in HTTPS subframes only

As of, we started strictly
blocking active mixed content loading inside subframes. However, this
turned out to break a lot of sites. Many of the broken sites are secure
sites framing insecure sites which load insecure subresources, and those
insecure subresources are strictly blocked because they are considered
mixed with respect to the top-level frame. The strict blocking doesn't
add a lot of security benefit in this situation, so this CL only applies
the strict iframe-subresource blocking when the subresource is mixed
with respect to the frame that loads it.

BUG= 582603 

Review URL:

Cr-Commit-Position: refs/heads/master@{#377921}


Labels: -Te-NeedsFurtherTriage M-50
Status: Started
The commit in #52 makes it so that HTTP subresources are allowed to be loaded if they are inside HTTP iframes; it's only active mixed content within HTTPS iframes that is strictly blocked. From what I understand this should resolve a fair amount of the breakage.

I'll request a merge to 49 once this commit passes through dev channel.
Comment 54 by, Feb 29 2016
Thanks estark. This would mean that if a user loads a http webpage in the iframe, all subresources are loaded too (but probably only when allowing loading unsafe scripts if the main URL is https)?

Would this also mean that when trying to a https website in an iframe, subresources in http are not loaded, but those in https are? This would mean that this is a different behavior compared to when loading a https website in the main page, as there http subresources are loaded (but the green padlock disappears) I think.
Re #54: if embeds, and tries to load, the mixed content shield will be shown, and blah.js will load if the user clicks through the shield. The green lock will then disappear and the red slashly lock will be shown instead.

If embeds which tries to load, the script will be strictly blocked and the shield won't be shown. The lock will remain green.

Note that all of this only affects *active* subresources such as scripts. In either of the above cases, if loads as an image, the image will be shown and the green lock will be removed.

Does that answer your question?
Thanks Estark. This is really helpful. Is your request to backport this fix to Chrome 49 getting considered ? Sorry for asking this but do we have defined dates when chrome v49 and v50 will roll out. 
Re #56: I'll request a merge to 49 once the commit has baked on Dev channel. The Chromium release calendar is here:
Thanks estark, that answered my question indeed, appreciated. Yesterday 49 was released, is this already in there, will probably be in 50?

Re #58: unfortunately, I missed the cut for M49, I'm so sorry! It did just make it in time for M50 though, so it'll be released there.
Thanks! Great that's in there for M50!
Status: Fixed
Sign in to add a comment