158

Reading through this doc: Docs.releasenotes.salesforce

We replaced the rich text editor in HTML Area home page components with a new version that supports more markup but doesn’t allow HTML to be manually entered.

In Summer ’15 we will start removing unsupported code from HTML Area home page components. As a result, components that contain JavaScript, CSS, iframes, or other unsupported markup might stop working properly. To use JavaScript or other advanced HTML elements in your home page component, we recommend that you use a Visualforce Area component instead.

With Visualforce homepage component the best we could do is design fancy home page components, which has not been the big use of sidebar amongst developers. How do we do the fancy hack we do today using html components since visualforce is hosted in a different domain will the sidebar hacks even work after summer 15?

You can include JavaScript in your Visualforce page, but because the component is rendered in an iframe on the home page layout, the JavaScript can’t interact with the page that contains the component.

Finally why this move :(?

Uwe Heim
  • 28,350
  • 18
  • 115
  • 283
Rao
  • 16,691
  • 13
  • 68
  • 108
  • 19
    They've been locking down the sidebar increasingly in order to apparently enforce a non-hacky UI. This causes me much displeasure, actually, because I've made so many useful things in the sidebar that will be broken when that comes out. – sfdcfox Jun 06 '14 at 22:52
  • 3
    @sfdcfox Since the doc says the page will be an Iframe, can I get the Iframe's parent window URL, and do the field changes using URL hack technique? Is cross domain javascript hack too complicated? – Rao Jun 06 '14 at 22:56
  • 4
    You can't do this because of Visualforce's separate domain, which causes browsers to activate sandbox security (meaning, the page can't access its container because of CSRF prevention). You could use HTML5's postMessage to get to the main page, but since we can't inject code into the page anyways, we're still out of luck. I'm going to write up an idea for this tonight. We need more power than what's available; I expect that next year, nobody's going to use the standard page, but instead create pure VF pages and set that as their landing tab. – sfdcfox Jun 06 '14 at 23:00
  • 5
    sfdcfox I am totally waiting to look at your solution :D. If you do come up with a solution please don't make it public, Salesforce techies might come up other ways to block your solution already:P LOL!!! – Rao Jun 06 '14 at 23:04
  • 3
    @sfdcfox One way I can found out recently was to use javascript in the custom button and alter the page contents, but this is very local to every page and to apply the JS common to all pages sidebar seemed the best option. – Rao Jun 11 '14 at 02:34
  • 1
    @rao For pages with no sidebar in the layout would I have to create a unique custom button for each object type (opportunity/account/task...) and page type (list/detail page buttons) combo where I want my JS embedded? Is there any way to create a single custom button and use it in multiple layouts? – odedbd Mar 29 '15 at 08:06

3 Answers3

144

ALERT UPDATE (Spring'16)

These workarounds were never supported by Salesforce officially. They have worked for many years but now the are no longer possible with the Spring'16 Update. It was announced by Salesforce in 2015 that even the workarounds described in the section below for Winter'16 are shut down with the Spring'16 Release, in February 2016. I verified it on different pods and can confirm it's over. Here are the details:

What is changing?

The Salesforce Technology team is updating code within the standard Messages & Alerts and Custom Links home page components, including JavaScript and custom HTML markup to comply with our evolving security architecture best practices. These changes will enhance the security of your organization.

End of Sidebar workarounds via Messages & Alerts and Custom Links finally in Winter or Spring '16? It's pretty clear and it looks like we have an end-date now.

The new Lightning Experience UI is still evolving. The Lightning Experience UI will probably make a lot of use cases for these workaround obsolete. At this time (2015-10) the new UI is not really feature complete. With the Spring '16 Release it's likely that many features required by typical customers might be there. However in my opinion it won't be possible to migrate all Orgs in 2016-02 on the Lightning Experience UI.

Unfortunately most (or all) of the limitations of the Aloha UI we found reasonable for considering those workarounds are still present.

So the decision to shut down the workarounds at this time can create some extra effort only for an intermediate time until most Orgs can migrate completely to Lightning Experience. It would have been nice, if Salesforce could allow us a little bit more "grace time" for those Orgs, e.g. in form of an critical update or in form of switching that "security improvement" off for one or two releases...

MODIFICATION UPDATE (Winter'16)

Here you can find a way which worked until Spring'16: Requirescript change in Winter '16 release

ORIGINAL POST (Summer'14 to Summer'15 )

At least up to Summer'15 there is a solution without HTML-Areas.

What does NOT work anymore:

New HTML-Areas are useless in Summer'14! Careful with existing HTML-Areas: you save it, you loose it in Summer'14. They get crippled!

It does not work in Winter'16 anymore! It had worked in Summer'14, Winter'15, Spring'15 and Summer'15. For Winter'16 you need this instead and with Spring'16 it looks like an end...

  • create a StaticResouce "YourStaticResourceName" upload a JS file containing whatever you need (e.g. jquery) and add a command in the end, like console.log('bingo!');
  • go to Setup > Home > Custom Links
  • create a new link call it "injection"
  • Behaviour = "Execute JavaScript"
  • Content Source = "Onclick JavaScript" (don't get irritated, you won't have to click!)
  • at the body enter {!REQUIRESCRIPT("/resource/1402932484000/YourStaticResourceName")}
  • go to Setup > Home > Home Page Components
  • create a new one
  • call it "injection-box"
  • pick type "Links" (instead of HTML-Area we used before)
  • click next
  • pick "injection" we created above
  • save it
  • got to Setup > Home > Home Page Layouts
  • add "injection-box" to your layout
  • go to anywhere it worked before and check for 'bingo!' in your console. See that 'YourStaticResourceName' is successfully injected to the standard pages :-)

This pattern works in a slightly modified version also for communities: Are sidebar Javascript workarounds also possible for partner portals / communities?

And finally it seems to be even officially supported, look at this: http://help.salesforce.com/HTViewHelpDoc?id=customize_functions_i_z.htm#REQUIRESCRIPT

Here you'll find a knowledge article about what is changing for HTML-Areas and a bit on "why" they do it: https://help.salesforce.com/apex/HTViewSolution?urlname=Home-Page-Components-Changes-Starting-Summer-14&language=en_US

Here you can find and contribute use-cases and possible alternatives for this pattern: Why do we still need to hack the Sidebar? Usecases - Workarounds - Alternatives

Hey guys let's join forces and somehow reach out together to Salesforce and explain to them as a group how important it is to keep the UI open.

Uwe

Community
  • 1
Uwe Heim
  • 28,350
  • 18
  • 115
  • 283
  • 4
    how awesome,never knew links had Java script :) , looks like an alternative route. Accepting this answer will give it a try and if it works it will help all the developers around. – Rao Jun 30 '14 at 15:41
  • 3
    We have created an framework of private managed packages using this technique. A Master-Package comes with an very easy setup processing the list above fully automated using metadata-api. Extension-Packages will then be detected automatically on install and cached. We have Extensions for dynamic height-adaption of layout-embedded vf-pages, way better country pickers (with preferred countries), dynamic 100%-width inputs (default width is fixed and too short), fixed-positioned header+tabs, orgName+Logo displayed permanently in the header, resizable sidebar and some more... ;-) – Uwe Heim Jun 30 '14 at 16:26
  • 4
    is there a way to hide this link from home page as only need to execute the script? – goodForce Jul 22 '14 at 07:24
  • 1
    Isn't it likely that SF will try to prevent this from working in the future too ? I'd just try to stay away from bypassing or hacking their UI all together. – Samuel De Rycke Jul 22 '14 at 07:35
  • 4
    @SamuelDeRycke : You are right, there is a risk. But since http://help.salesforce.com/HTViewHelpDoc?id=customize_functions_i_z.htm#REQUIRESCRIPT it may end up a bit harder for SF to remove it. My first hope is, that we can show (to SF) that we don't use it for hacks but for very meaningful, reusable and important improvements of the UX. There are so many examples... My second hope is, that Aura will bring enough freedom that we don't need this approaches anymore. My impression is, that you can customize and reuse things way better with Aura than it was ever possible with Visualforce. – Uwe Heim Jul 22 '14 at 07:44
  • 6
    @deva : Yes there are many ways. What I usually do is to use this method to load either jquery or an CSS file which sets the entire display of "injection-box" to none. I use firebug to figure out the right selectors. So not only the link is hidden, but also it's container. Since this happens after an async load, the box is typically visible for a very short time. This could be avoided if you place some inline JS right into the {!REQUIRESCRIPT(data:application/javascript;base64,...)}. To encode rot47.net/base64encoder.html - then it should be totally hidden from the very beginning. – Uwe Heim Jul 22 '14 at 07:53
  • @UweHeim you are a pure genius, this approach works like charm :) – Rao Aug 05 '14 at 20:32
  • 1
    @Uwe Heim, this was great, thanks! I made a blog post of using your technique to embed google analytics http://douglascayers.blogspot.com/2014/08/add-google-analytics-to-salesforce_17.html – Doug Ayers Aug 17 '14 at 19:02
  • @UweHeim I don't think this technique can work on an Edit page because custom links / buttons don't show on Edit. Do you have any alternatives for that? – Dominic Aug 21 '14 at 09:32
  • @dominic if you follow all the points above exactly, it WILL work - and yes, even on edit pages. Please note we use again the sidebar to host the links/button. So they will be present. – Uwe Heim Aug 21 '14 at 10:08
  • 1
    Excellent answer. If you're looking to use this updated method to resize embedded visualforce pages dynamically, see my answer here – Luke Willis Feb 11 '15 at 19:45
  • 1
    Will the resource path be kept if I package the resource+custom link+hope page component into an unmanaged package and install it on a different SF installation than where it was created? – odedbd Mar 04 '15 at 19:52
  • In an unmanaged package there is no difference - it simply works. In managed packages it works, too - but you need to compose the path dynamically or hardcode your prefix. I use this in managed packages and it works like a charm. But you have no chance to pass the security review with your App. Let's hope the security team will show some mercy and let us go on until Salesforce comes up with an official solution for our most pressing needs. – Uwe Heim Mar 04 '15 at 20:04
  • 1
    @UweHeim Thanks for your reply. I didn't even think about trying to submit this as a managed package since it is an obvious no go. But an unmanaged package is perfect for my current use case, so this is a huge help. Much appreciated! – odedbd Mar 04 '15 at 20:08
  • @odedbd - if it was helpful, consider upvoting the question of rao above. – Uwe Heim Mar 04 '15 at 20:14
  • The update rolled out for my org over the weekend. Fortunately I'd already made the custom links as per above and swapped over to them with no issues. Thanks @UweHeim !! – ianbailey Jun 15 '15 at 09:36
  • 1
    @UweHeim - do you know if there is any way to get this working in the Search results page, where there is no sidebar? Is there a way to add a custom link or button specific to the Search results page? – odedbd Aug 26 '15 at 17:11
23

The policy announcement is very clear:

In Summer ’15 we will start removing unsupported code from HTML Area home page components. As a result, components that contain JavaScript, CSS, iframes, or other unsupported markup might stop working properly. To use JavaScript or other advanced HTML elements in your home page component, we recommend that you use a Visualforce Area component instead.

Note that it says "we will start removing unsupported code from HTML Area home page components".

Do not risk wasting your dev time finding some mechanism to inject third party javascript which has not yet been removed and assume that it will never be removed.

Take the policy at face value and assume that all mechanisms that allow third party javascript to be injected into the saleforce homepage will be removed at some point.

As to the reason for this policy, it's pretty clear why having a separate namespace and security domain between salesforce.com javascript code and third party javascript code reduces conflicts and makes it easier for all sides to properly test and secure their code.

Robert Sussland
  • 3,234
  • 14
  • 22
  • Hi Robert, thaks for your clarification. This helps all of us to plan ahead. A view days ago I noticed that a partner alert has been updated in which context an new question came up: http://salesforce.stackexchange.com/questions/68587/end-of-sidebar-workarounds-via-messages-alerts-and-custom-links-finally-in-win – Uwe Heim Mar 08 '15 at 10:57
11

Other answers have a pretty good overview of the current workarounds within Salesforce and the reasons for this change (security).

However, one possible workaround feasible for controlled internal environments, would be to write a browser extension to handle this. For example, it's pretty trivial to write a Chrome extension that executes JavaScript on a given set of pages. Then, with managed deployment, this extension could easily be deployed to an entire organization as long as your use case is internal. Of course you could probably do the same with other browsers as well.

The main challenge is that we can't get JavaScript onto the main Salesforce page so we can't modify the height of the iframe. Writing this logic in an extension solves this challenge.

Of course this is somewhat of a last resort solution, but the great part is that you're not counting on ticking timebomb of using any hacks that are on their way to not working forever.

jon_wu
  • 777
  • 7
  • 22
  • 3
    Yes this would be a desperate very last measure. For Firefox there is an addon called Grease Monkey which lets you inject custom JS on any site. Still the effort on the client side is to high to justify it in most use-cases. I'm still very unhappy with the salesforce decision simply to close the workarounds without providing a viable solution for Aloha-UI use-cases. Only the Lightning-UI might overcome this pressure, but I can't roll it out in the current condition on all the Orgs which are falling into LoFi mode now... it's not only the iframe height, there are the bad sized input fields, etc – Uwe Heim Jan 20 '16 at 20:19
  • 4
    I'm pretty sure LockerService won't allow this either. Cool idea, though. – sfdcfox Jun 20 '16 at 06:51
  • 2
    Seems like you could still enable communication somehow if you get creative. Perhaps through polling localStorage if that's allowed, or maybe using the Lightning eventing framework, or even getting wild and seeing if you could inject public methods into the Lightning API (probably the most difficult and brittle way to go). I haven't written any Lightning stuff yet so this is just theoretical. – jon_wu Jun 21 '16 at 17:27