Normalized event difference with ShadowDOM and Shady

[atoy40]

Hello,

i've an element which contains a paper-fab, and a tap event as :

<dom-module id="my-toolbar">
  <template>
     <paper-fab on-tap="myHandler" icon="..."></paper-fab>
     <paper-fab on-tap="myHandler" icon="..."></paper-fab>
     <paper-fab on-tap="myHandler" icon="..."></paper-fab>
  </template>
</dom-module>
<script>
  Polymer({
    is: 'my-toolbar',
    myHandler: function(e) {
      console.log(Polymer.dom(e));
    }
  });
</script>

This element is instantiate into a tree of other elements, starting from a top element "my-app" instantiated in the html body.
I've one unique handler for 3 paper-fab. So in the handler, i want to identify the clicked paper-fab.
but i found in the normalized event object that :

• with Shady
  • localTarget : is the app top element "my-app"
  • rootTarget : the "sub element" of paper-fab you click on (for example iron-icon if you click at the center)
• with ShadowDOM
  • localTarget : is the app top element "my-app" too (is it correct ?)
  • rootTarget : is the paper-fab element you click on (seems to be the correct behavior to me)

Anthony.

[kevinpschaaf]

The expected result is the following on both Shady & Shadow:

• rootTarget: iron-icon (deepest element that was tapped)
• localTarget: paper-fab (element that had the event listener)

The discrepancy appears to originate in the gesture system. Using click results in the expected results (same between shady & shadow)

http://jsbin.com/lohepic/edit?html,console,output

[atoy40]

It's strange, i've tested it with a click, and localTarget always seems to be my app top-level element, on both shadow and shady.

[atoy40]

Wow, forget my last words. I made a mistake : i was logging Polymer.log(e), and then i was clicking on the localTarget property in chrome console to resolve the "getter" ... and it seems it's not correctly resolved (context problem ?)

[timeu]

@kevinpschaaf
I am not sure if this is related to this issue here. But what is the designed behavior when using an annotated event handler on the Local DOM which contains Light DOM elements. I modified your JSBIN and the only get the <h1> as event target: http://jsbin.com/qewahodoxa/edit?html,console,output.

I was expecting to get <x-test> at some point.

[kevinpschaaf]

Right, the object returned from Polymer.dom(e) has getters that are evaluated lazily, and the event target changes once the event loop completes, so you may see different results if you expand the object on the console later.

You should never expect to see x-test as a target unless the event handler was placed on or above x-test. Since the handler is on elements in the template stamped inside of x-test, localTarget gives you the first element inside the x-test scope (but at or below where the handler was added) as the event bubbles up, while rootTarget should give you the deepest-most element irrespective of scope boundaries (which may or may not be the same thing).

As I said, the bug appears to originate in the gesture system, as it is only the gesture-simulated events that have incorrect targets, not native ones like click.

[timeu]

@kevinpschaaf
I see but in the JSbin I posted, I placed the on-tap and the on-click handler on the x-test element and still get <h1> as localTarget:

<x-test on-click="myHandler"><h1>Click</h1></x-test>

[dfreedm]

This is just a holdover from the initial design, where gesture events were non-bubbling. Should be pretty easy to change the initiator from nativeEvent.currentTarget to nativeEvent.target.

[dfreedm]

Ah, so the real problem is that when the event gets to the gesture recognizer, it has already passed through the shadowdom boundary and lost the original target. I'll have to use event.path in the recognizer to fire from the original source.

@kevinpschaaf we may to discuss the performance impact of this for ShadyDOM.

[jaichandra]

@kevinpschaaf @azakus This one could still be an issue. Or I might be doing this all wrong. I updated @kevinpschaaf jsbin to pass content as light DOM and I understand that Light DOM is ignored here and I therefore get content are localTarget. But, shouldn't it be paper-fab as localTarget? content doesn't seem to be of any use here.
http://jsbin.com/golome/edit?html,console,output

[jaichandra]

Looks like this is certainly a bug with ShadyDOM. If I enable ShadowDOM in above sample, it works. The problem is with ShadyDOM.
http://jsbin.com/golome/edit?html,console,output