Apex Code Development You need to sign in to do that
Don't have an account?
Gennadiy Salesforce Defect in VF homepage components?
We have encountered a strange issue in a customer Sandbox. A VF homepage component generates relative URLs, but in other orgs it generates absolute URLs. Is this an internal defect, or is it a configuration that we don’t know about?
In the sandbox is a Visualforce homepage component based on a simple custom VF page. This component is added to the left sidebar in classic SF UI. It works fine on standard pages and on other custom VF pages.
BUT when we try to open a VF page from any AppExchange package, the sidebar component fails and we see the “URL No Longer Exists” error inside it.
We analyzed the HTML-code in a browser and found that it fails because Salesforce does not use the correct URL for an iframe which is generated for the home page component.
Pages from AppExchange packages are based on a specific domain name (unique for every package). Example of a page from the "mea" package:
In all other orgs where we tried to reproduce this issue, Salesforce generates absolute URLs for the same iframes and they work good:
Other AppExchange packages cause this same issue in this sandbox, but work correctly in other orgs.
Why would Salesforce generate incorrect URLs only in this sandbox?
In the sandbox is a Visualforce homepage component based on a simple custom VF page. This component is added to the left sidebar in classic SF UI. It works fine on standard pages and on other custom VF pages.
BUT when we try to open a VF page from any AppExchange package, the sidebar component fails and we see the “URL No Longer Exists” error inside it.
We analyzed the HTML-code in a browser and found that it fails because Salesforce does not use the correct URL for an iframe which is generated for the home page component.
Pages from AppExchange packages are based on a specific domain name (unique for every package). Example of a page from the "mea" package:
https://mea.cs52.visual.force.com/apex/MassEditAllActivitiesIn the defective sandbox, Salesforce generates the following iframe for a sidebar component (NOTE that it uses a relative URL):
<iframe frameborder="0" id="contentPane"
onload="initContentFrame('/apex/MyCustomPage, true, false , https://cs52.salesforce.com' );"
src="/blank.html" style="width: 100%; height: 100%">
</iframe>
As a result, a browser tries to open the following URL in the iframe:
https://mea.cs52.visual.force.com/apex/MyCustomPageSince the custom page is not a part of the MEA package this URL does not work.
In all other orgs where we tried to reproduce this issue, Salesforce generates absolute URLs for the same iframes and they work good:
<iframe frameborder="0" id="contentPane"
onload="initContentFrame('https://na14.visual.force.com/apex/MyCustomPage, true, false , 'https://na14.salesforce.com' );"
src="/blank.html" style="width: 100%; height: 100%">
</iframe>
Other AppExchange packages cause this same issue in this sandbox, but work correctly in other orgs.
Why would Salesforce generate incorrect URLs only in this sandbox?
At the same time, I don't think this explains something to solve our problem. In our dev org Visualforce pages are hosted on another domain than standard SF application too, but the described issue does not happen there. The defect is in internal SF mechanism which generates HTML for the sidebar: it uses relative URL instead of absolute one.
I think because of security reasons Salesforce introduced different domains for standard pages, custom VF pages and VF from 3rd part packages. As far as I understand, SF has done it some time ago, but originally everything worked on the same domain.
For example, previously a single domain was used for all pages (standard, custom, from packages) and it could look like this: https://na30.salesforce.com
Now, in our DEV org domains look like this:
For standard pages: https://na30.salesforce.com
For custom pages: https://c.na30.visual.force.com
For pages from managed packages: https://PACKAGE_NAMESPACE.na30.visual.force.com
In the defective sandbox org domains look like this:
For standard pages: https://cs52.salesforce.com
For custom pages: https://cs52.salesforce.com
For pages from managed packages: https://PACKAGE_NAMESPACE.cs52.visual.force.com
So, domains for custom pages and standard pages are still the same in the sandbox. If the same domain is used for packages, then relative URLs for iframes in the sidebar would work, but it's not the same. As a result, I can conclude that Salesforce pushed/enabled upgrades to this sandbox partially: a different domain for packages is used now, but the system still think that everything is based on one domain. This may explain why SF still uses relative URLs for the sidebar components.
But it's still not clear how to solve this problem without full refresh of the sandbox.
https://cs52.salesforce.com/apex/PACKAGENAMESPACE__PageName
Then SF introduced new domains that I mentioned in the previous post (I do not remember when it happened exactly, maybe 1 year or more ago). So, now this defective sandbox (as well as all SF orgs) always opens VF page from package in a new domain:
https://PACKAGE_NAMESPACE.cs52.visual.force.com
But this sandbox still opens custom VF pages in the same domain as standard pages. And it makes me think that the mechanism for managed packages was updated for this sandbox (as well as for all other orgs), but other things were not changed and internal infrastructure in this sandbox still considers that everything works in one domain. That's why it uses relative URLs for iframes.
It's not clear why it happened so.