Apex Code Development You need to sign in to do that
Don't have an account?
Winter 13 bug or breaking change - No VF pages on page layouts with clickjack protection?
Currently Winter 13 ClickJack protection prevents use of VisualForce pages on page layouts. Is this a bug or a change?
Steps to reproduce (Winter 13 sandbox):
Create the following VisualForce page:
<apex:page StandardController="Lead">
<!-- Begin Default Content REMOVE THIS -->
<h1>Congratulations</h1>
This is your new Page
<!-- End Default Content REMOVE THIS -->
</apex:page>
Add it to a lead page layout.
Now go to Enable Setup-Security Controls – Session Settings and select Enable clickjack protection for non-setup customer Visualforce pages
When you view a lead, you'll see an error:
"URL No Longer Exists". You have attempted to reach a URL that no longer exists on salesforce.com
I read the info in the release notes - does this really mean that enabling this protection prevents all use of VisualForce pages on a page layout? That would be a huge breaking change for which there is no workaround.
Use showHeader="false" to re-enable the page. This is a feature.
Hmmpphh.. Well, I've verified that it works. I'm not a huge fan of this as a solution though - as it likely will require anyone who wants to turn this protection on to not only upgrade any places where they use a VisualForce page on a layout, but to reach out to the developers of any applications that use it and convince them to make the necessary changes and update their packages.
So, in my book, this is a "workaround" - not a feature. It doesn't change the fact that turning clickjack protection on breaks a huge amount of code. Also, if it were a "feature", the way to address it should have been included in the release notes, and it should have been communicated properly. In fact, the partner notice should have clearly noted the required change. In fact, SFDC should have reviewed existing VF pages (which they can do), and notified every org with one of those critical update warnings to notify orgs that have this problem that this issue can occur and to be proactive about dealing with it. This should have been done weeks or months before the release so there is time for developers and ISVs to deal with it - an not buried in a forum post a few weeks before Winter 13 goes live.
Also, the currently error is UGLY - a truly awful user experience.
So no - this is a workaround for a bug. Or it's an excuse. But it's definitely not a feature.
Dan
I agree that the design is half-baked, and I think, furthermore, that this feature would have been effective if it blocked pages with "showHeader="true"" explicitly coded; it could be assumed that the developer meant the window to be a top-level window. This is significant, because you can embed pages on page layouts, and that page might also be used full-screen, but if it were part of a page layout, it should not show its header, but in the full page, it should. I can see how this effect means that many more components will apparently be necessary to support multiple versions of the same page whose only difference is that one is embedded in a page layout, and the other not. Their clickjack protection should kick in only if the outer frame isn't a force.com domain instead of being agnostic to the outer frame's domain.