Greetings great people of the Salesforce Stackexchange,

We are having some trouble with Salesforce Locker Service update in the custom Lightning Components we're developing.

This works without Locker Service enabled, but breaks with it turned on.


<aura:iteration items="{!v.results}" var="result">
    <li class="slds-dropdown__item">
        <a onclick="{!c.select}" data-object="{!result.stringified}">{!result.Name}</a>


select: function(component, event, helper){

    var valueObject = JSON.parse(event.target.getAttribute('data-object'));


With LockerService enabled, valueObject is null.

The event object looks like this: Preview of the event object in the console

event.target outputs as an empty object in the console: {}

We've tried event.getTarget(), event.getSource(), event.currentTarget and tons more examples we found throughout official Salesforce documentation, but without result.

How can we know what the user has clicked on with Locker Service?

Please liberate me from my ignorance. :)

  • Looks like you may want to use event.getSource().. developer.salesforce.com/docs/atlas.en-us.lightning.meta/… Nov 8 '16 at 14:33
  • Thanks for responding! I read somewhere event.getSource is for built in lightening components only. When I use it I get "event.getSource is not a function". Nov 8 '16 at 14:36
  • That is correct - there are 2 types of events being passed around in Lightning: Aura and DOM. For DOM events the code in the origin post looks correct. @joshuadelange what does event.target look like under locker? Can you also provide the results of eval'ing this in the js console: event + "" Nov 8 '16 at 14:42
  • @DougChasman Thanks for your help! event.target outputs as an empty object in the console: {} Nov 8 '16 at 14:49
  • 1
    I'm looking for: event + "" not event.target as I think the issue is further upstream Nov 8 '16 at 14:56

I believe the issue here is at the intersection of aura:iteration and Locker resulting in a sort of custody battle over ownership of the resulting DOM. Opened bug W-3458193 to track this.

  • So, you mean that his component is losing the ownership of the DOM element because of the aura:iteration which kind of "steals" it ? Nov 8 '16 at 15:10
  • 3
    Exactly - opened W-3458193 to track this and the Locker team is investigating now Nov 8 '16 at 15:14
  • @DougChasman Thank you Doug! Were you able to hear anything back from them in the last week? Nov 16 '16 at 14:55
  • @joshuadelange This seems to be fixed now. I have verified it in the Spring 17 release. Here's the component markup I used gist.github.com/anonymous/fcf2e7aee13d3d9f8cc2e125c5c9174b Please let us know if its still a problem. A git gist of your code showing sample data in v.results would be useful. Jan 12 '17 at 0:10

Yes it's a big problem for now.

event.target, event.currentTarget are undefined because of locker service. I think they are suppose to fix it in a next release but for now you may need to create your own component "dropdownItem" and pass the data object as an attribute. Then after handling an onclick event triggered by your component you will be able to do event.getSource().get("v.dataObject").

If you need help with it I can give an example.

  • Ouch! Any ideas when Salesforce will have this fixed? Nov 8 '16 at 14:47
  • Hold on a second Lucas - the post you linked to was about reaching into the internals of a component you do not own (lightning:buttonIcon) that has a design flaw in it that is being corrected. Not the case in the code above. This is not a bug in Locker - it is simply doing its job. The team that owns the lightning: namespace has been alerted, I opened a bug to track it etc and they said it would be fixed by now. Appears to have missed the boat for the current patch. Sigh. Nov 8 '16 at 14:54
  • Oh okay @Doug. I agree with you my link is not a good example. So what do you mean about "simply doing its job" ? A component cannot access its own DOM elements anymore ? What would be your workaround for this ? Nov 8 '16 at 15:02
  • 3
    The open bug for the team that owns the lightning: namespace is W-3453049 if you want to reference this in any communications with Salesforce. They are working on it but do not have an ETA yet. Nov 8 '16 at 15:06
  • Thank you ! I deleted the link from my answer as it was not relevant. Nov 8 '16 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.