157

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 :(?

Improve this question
6
  • 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 6, 2014 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 6, 2014 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 6, 2014 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 6, 2014 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, 2014 at 2:34

3 Answers 3

Reset to default
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

Improve this answer
17
  • 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, 2014 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, 2014 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, 2014 at 7:24
  • 4
    @SamuelDeRycke : You are right, there is a risk. But since help.salesforce.com/… 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, 2014 at 7: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, 2014 at 7:53
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.

Improve this answer
1
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.

Improve this answer
3
  • 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, 2016 at 20:19
  • 4
    I'm pretty sure LockerService won't allow this either. Cool idea, though.
    – sfdcfox
    Jun 20, 2016 at 6: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, 2016 at 17:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .