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!