End of javascript sidebar workarounds? (Salesforce Classic / Aloha)

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

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

    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 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!!!

    @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 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?

  • Uwe Heim

    Uwe Heim Correct answer

    7 years ago

    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

    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.

    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... ;-)

    is there a way to hide this link from home page as only need to execute the script?

    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.

    @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.

    @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.

    @UweHeim you are a pure genius, this approach works like charm :)

    @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

    @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 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.

    Excellent answer. If you're looking to use this updated method to resize embedded visualforce pages dynamically, see my answer here

    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?

    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.

    @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 - if it was helpful, consider upvoting the question of rao above.

    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 !!

    @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?

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM