function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
GennadiyGennadiy 

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:
https://mea.cs52.visual.force.com/apex/MassEditAllActivities
In 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/MyCustomPage
Since 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?
sfdcsushilsfdcsushil
Hello, I dont think it will work. Read this thread, you may get some insights - https://developer.salesforce.com/forums?id=906F0000000950rIAA
GennadiyGennadiy
Hi sfdcsushil. Thank you for the link.
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.
sfdcsushilsfdcsushil
Ok. Here is the thing, in client org(prod or sandbox), any pages created by client are loaded in their domain. But if they load app exchange package page, it's loaded in completely different domain(your domain). So anything sitting on side panel will also be tried through your domain and it will fail. This is all related to security. This is my understanding. Even i have not worked on any similar thing. I am just trying to understand based on below link.
GennadiyGennadiy
Thank you, sfdcsushil. You pushed me in a new direction.

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.
sfdcsushilsfdcsushil
Hello, If I open any VF page from package in prod, it always open in separate domain(Not the actual domain of org). So I don't think it's something new in your sandbox. It has been there for a while. -Sushil
sfdcsushilsfdcsushil
By any chance you have choice of just hiding the sidebar. Then I would suggest just hide the sidebar in your vf page.
GennadiyGennadiy
Previously, pages from packages were hosted on the same domain and URL for them looked like this:
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.