I am currently creating a managed package and am running into a problem which I think others will or have also faced while deploying a package using lightning components which are optionally wrapped in VF inline-containers for backwards compatibility.

Problem is as following:

Unsafe attempt to load URL https://wsone.eu11.visual.force.com/resource/1478396169000/WSONE__SLDS/assets/icons/action-sprite/svg/symbols.svg#priority from frame with URL https://wsone-data.eu11.visual.force.com/servlet/servlet.Integration?lid=06…1TMHdPVlF3TVRvME5qbzFPQzR6TmpSYSw2YlV5cDZTTl9GSHZham9iNmVkTXVMLFlXWmtNR0po. Domains, protocols and ports must match.

This seems to occur because the iframe is run from the url {page-location}.instance.visual.force.com - but any subsequent requests to images/resources on this URL send a 302 redirect to the {namespace}.instance.visual.force.com domain - causing them to be rejected by the browser because of iframe cross origin policies. The {page-location} in my case is an extension package (wsone-data), but also seems to occur when hosting the page locally on the instance (c.eu11.visual.force.com).

The exact situation I have

  • Core managed package including lightning components which are globally accessible
  • The core package contains a VF component which uses lightning-out to render a lightning component
  • Extension package contains a VF page which above component
  • In the lightning component I reference to an external resource through a reasonable method ({!$Resource.SLDS + '/assets/icons/standard-sprite/svg/symbols.svg#forecasts'}) - results in a /resource/1478396169000/{namespace}__SLDS/ href in any case

Some time ago this all worked wonderfully - it seems that either Winter '17 (or one of the unannounced patches??) has broken something here.

So far I've tried to hardcode the href to be prefixed with the domain the iframe is running in - but that logically makes no difference as a 302 redirect is still served.

Am I doing something stupid here or missing an obvious workaround? The only thing I can think of is to try to use newly introduced lightning:icon - would however not be surprised if this will show the same problem - but using this component will result in new problems such as a HTML structure not conform to what SLDS demands in certain cases.

All clues and comments welcome!

  • 3
    This looks like a bug to me .You might want to raise a case with support and i feel same that one of the patches might have broke Nov 6, 2016 at 2:11

1 Answer 1


I've managed to create a temporary workaround by adding the SLDS zipfile to the extension package and then detecting whether I need to use this based on the url. Something in the form of:

var svgPath = component.get('v.svgPath');
if (window.location.href.indexOf('wsone-data') > -1) { // in case of extension package
    svgPath = svgPath.replace('WSONE__SLDS', 'WSONE_DATA__SLDS');
} else if (window.location.href.indexOf('https://c.') > -1) { // in case of non-managed usage - requires SLDS.zip to exist in consumer org
    svgPath =  svgPath.replace('WSONE__SLDS', 'SLDS');
  • Any solutions for VF pages? Getting the same error. Looks CORs related. Jan 27, 2017 at 7:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .