Know Which Features to Avoid in Lightning Experience

Learning Objectives

After completing this unit, you’ll be able to:

• List at least two components to avoid using on pages used in Lightning Experience.
  
• Identify three Lightning Experience features where you can’t use Visualforce pages or components.
  

Knowing Which Features to Avoid in Lightning Experience

There are a limited number of Visualforce components that we recommend you avoid on pages used in Lightning Experience. Additionally, a few features of Visualforce behave differently when used in Lightning Experience. Finally, there are a few places in Lightning Experience where you can’t use Visualforce pages or apps, or where they might not function as expected.

Lightning Experience is still evolving and growing, and—Safe Harbor alert!—we hope to shrink this list as time goes on.

Lightning Experience Header and Navigation Menu Can’t Be Suppressed

Visualforce pages always display with the standard Lightning Experience user interface when they run in Lightning Experience. There’s no way to suppress or alter the Lightning Experience header or sidebar. In particular, the showHeader and sidebar attributes of <apex:page> have no effect on Visualforce pages when displayed in Lightning Experience .

This behavior is intentional. Apps that display in Lightning Experience are Lightning Experience apps. If you need to provide a completely custom interface for your app, you’ll need to run it in Salesforce Classic.

Salesforce Classic Header and Sidebar Are Always Suppressed

The standard Salesforce Classic header and sidebar are always suppressed for pages when they’re displayed in Lightning Experience. In particular, the showHeader and sidebar attributes of <apex:page> have no effect on Visualforce pages when displayed in Lightning Experience.

Pages behave as though the showHeader and sidebar attributes of <apex:page> are both set to false.

The standardStylesheets attribute of <apex:page>, which determines whether to include or suppress the standard Salesforce Classic stylesheets, is unaffected by Lightning Experience. That is, it defaults to true in Lightning Experience, but you’re able to change it.

<apex:relatedList> and Blocklisted Related Lists

There are a number of related lists that aren’t supported in Lightning Experience. These related lists are “blocklisted,” which means they are explicitly prevented from being used. As you might expect, these same related lists are blocklisted in Visualforce with the <apex:relatedList> tag.

See “Data Access and Views: What’s Different or Not Available in Lightning Experience” in the online help for details of which related lists aren’t supported in Lightning Experience.

Avoid <apex:iframe>

While it’s not impossible to use <apex:iframe> on a Visualforce page in Lightning Experience, we recommend avoiding it.

Visualforce pages are wrapped in their own iframe when displayed in Lightning Experience. As discussed at length in Exploring the Visualforce App Container, this has a number of significant implications for how the page behaves. Adding an additional level to the iframe stack increases the complexity of the environment.

You can manage this complexity if you understand iframes and how they affect the DOM and JavaScript. However, it's difficult to debug nested iframes if you don't have experience working with them. For this reason, we suggest avoiding this tag on pages used in Lightning Experience.

No, Really, Don’t Set window.location Directly

We probably sound like a broken record at this point, but it’s important. If your page’s JavaScript code is setting the window.location variable directly, that won’t work when the page is displayed in Lightning Experience. You must modify this code for the page to work in Lightning Experience.

See the Managing Navigation  unit for details.

sforce.one Isn’t Salesforce Mobile-Only

The sforce.one JavaScript utility object is available to Visualforce pages in both the Salesforce app and Lightning Experience. If you’ve been using the presence of the sforce.one object as a way to tell if your page is running in a mobile or desktop context, you need to update your code.

Use one of the documented methods to distinguish between the Salesforce Classic, the Salesforce app, and Lightning Experience environments. Supported techniques are available in Visualforce, Apex, and JavaScript.

For the full details, see the Sharing Visualforce Pages Between Classic and Lightning Experience  unit.

Changes With Action Overrides

Perhaps the most significant change, in terms of things that might be hard to work around, Visualforce overrides of standard actions are slightly different in Lightning Experience compared to Salesforce Classic. Any override for the object list action won’t be accessible in Lightning Experience.

Specifically, there are six standard actions you can override for most standard and all custom objects in Salesforce Classic:

• Object tab
  
• Object list
  
• Record view
  
• Record edit
  
• Record create
  
• Record delete
  

In Lightning Experience the first two actions have been combined into one page, object home. Object home is similar to object list, along with some elements of object tab, like recent items. Other elements, such as reports or tools, have moved to other parts of the user interface.

Regardless of the user interface settings in your organization, both object tab and object list are available to be overridden in Setup. Overriding the object tab action overrides the object home page in Lightning Experience, as expected.

However, when in Lightning Experience, the object list action isn’t accessible in the user interface, so there’s no way to fire it. If your organization has overridden the object list action for any object, that functionality won’t be available when users are using Lightning Experience. If there are essential features in that override, you’ll need to find another way to make them available.

This table lists the standard actions you can override for an object in Setup, and the action that’s overridden in the three different user experiences.

“n/a” doesn’t mean you can’t access the standard behavior, and it doesn’t mean you can’t override the standard behavior. It means you can’t access the override. It’s the override’s functionality that’s not available.

Resources

• Overriding an Existing Page with a Visualforce Page
• Visualforce Developer’s Guide