I need to implement secure communication between Visualforce embedded on a Lightning Component. The LC sits on a Flexipage.

One of my goals is, that the VF-page sends it's actual height to the LC so that the LC can adjust the height of the iframe. Fixed heights are always killing UX. But many, many other meaningful and painfully needed use cases can be solved using the same secure communication method.

Now without Locker Service the world is fine with this markup:

<aura:handler name="init" value="{!this}" action="{!c.init}" />
<iframe src="/apex/yourVisualforcePageName" width="100%"></iframe>

And this controller:

init : function(cmp, evt, hlp) {
    window.addEventListener("message", elfMessageRouter, false);
    function elfMessageRouter(event) {

Usage is simple:

window.parent.postMessage( { foo: "bar", height: 123 } ,'*' );

And you get something nice in your console:

RECEIVED Object {foo: "bar", height: 123}

But now comes Locker Service... I go to Setup > Critical Updates and turn that baby on, I change nothing, reload my page in LEX and get only:

RECEIVED Object {}

Which shows that the process works but the parameter is busted.

How this can be optimized? Is this communication method at all accepted or considered as some kind of threat or unwanted feature?

Btw. the fixed-iframe-height was my main pain point for nearly 10 years of Aloha-live... Many have asked for dynamic sized embedding containers on standard layouts - but they never came. Then (out of desperation) we came up with crap like these hacks: Why do we still need to hack the Sidebar? Usecases - Workarounds - Alternatives

How we can do it right now and secure from the beginning?

  • This is working fine for a Lockerized Lightning component communicating to an iframe in it's markup and back. The issue likely surfaces when you use a VF page. Would it be possible to share your source (or a simplified example) of what your VF page looks like and how exactly you're executing the Javascript to send a message from the VF page back to the Lightning page? Dec 26, 2016 at 19:46
  • Hi @TrevorBliss as said it's working but only if you avoid an object message and send primitives like string or numbers. All relevant parts of code are present to verify that behavior. Turning Locker Service off you can use objects, too. I suspect that Locker Service explicitly forbids objects, because you could pass references of e.g. the window object itself. But an clarification would help, because I can't read this limit out of the documentation.
    – Uwe Heim
    Dec 27, 2016 at 8:13
  • @TrevorBliss put in the visualforce page only this javascript and you see it window.parent.postMessage( { foo: "bar", height: 123 } ,'*' );
    – Uwe Heim
    Dec 27, 2016 at 8:18
  • There must be something else to this repro. I have Locker enabled and I copy/pasted your exact markup and controller file. The Visualforce Page only contains <script>window.parent.postMessage( { foo: "bar", height: 123 } ,'*' );</script> and the console prints an object with both the foo and height property set. This works for me in a standalone app and in LEX for an app built via Lightning App Builder. Dec 27, 2016 at 23:45
  • And to clarify, LockerService is not explicitly blocking objects from being passed in postMessage. Dec 27, 2016 at 23:53

2 Answers 2


According to the SecureWindow Locker Service API tests, postMessage is supposed to be supported:

Method      Test Plan (expected)    Browser API (actual)    Locker API (actual)
            Type    Empty   Opaque  Type    Empty           Type    Empty   Opaque
postMessage function                function                function    

Since they're expecting a function, and it states that tests are actually passing at the moment, postMessage should be allowed in the future.


First thing I thought, OK, let's do it with morse-code, then ;-) But no kidding, it works in the current release of Locker Service a little bit better. What I found is that actually I can at least use a string parameter like this:

 window.parent.postMessage( "foobar" ,'*' );

This brings at the receiver this:


Which is good enough for me to help myself. But looking a bit deeper into my console, I see a string attached. There is a warning by aura_proddebug.js:19408:

WARNING: Error in filesManagerHelper while parsing post message dataSyntaxError: Unexpected token o in JSON at position 1

Does this show only a small glitch in the Locker or is the a bug or an incomplete "feature" which will kill my entire communication eventually?

Will Locker Service allow us a reliable way to make Lightning Experience and Visualforce communicate securely, stable and reliable together? Will Salesforce provide us mechanisms of doing so? Are we allowed to help ourselves? Or is this unwanted at all?

  • 3
    Technically, this should probably be edited into your question.
    – sfdcfox
    Dec 23, 2016 at 14:47

You must log in to answer this question.

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