Safari & actions on native elements: Function statements must have a name.

[rlivsey]

TLDR: http://jsbin.com/xuquqa/edit?html,js,console,output

I've seen a few demos doing the rounds of how awesome the new actions helpers are in combination with native elements, eg:

  <select onchange={{action "selectChanged" value="target.value"}}>
    {{#each items as |item|}}
      <option>...</option>
    {{/each}}
  </select>

This works great in Chrome, but in Safari this results in an error when the event is triggered:

SyntaxError: Function statements must have a name. (line 1)

The JSBin has examples of input and select both of which raise the same error.

[rwjblue]

I believe that this is a duplicate, and that we are unlikely to fix (unless someone knows what the solution to this cryptic error is off hand), as we intend to submit another RFC for something that I have been calling 'kabab actions'. The idea is to enable per element / event handling like your example above, but still use our standard event dispatcher (this avoids adding a ton of event listeners).

[rlivsey]

Cool, I couldn't find a duplicate issue but must have missed it - I'll close this one.

I wasn't sure it was intended to be supported, seemed like a "happy" accident, but as I'd seen all the demos knocking about I thought I'd give it a go.

Makes sense to go through the dispatcher as opposed to going back to the 90's and attaching handlers all over the shop.

[rwjblue]

No worries, I could be wrong about the dupe (SO MANY EMAILS 😺 ).

[stefanpenner]

lets keep this open until a duplicate is linked.

[stefanpenner]

I believe this is a bug in Safari. Which results in our detection code being thrown off.

@rwjblue this is directly related to my email yesterday.

[stefanpenner]

let me confirm

[cibernox]

This could have been terrible news for me. Glad I haven't enabled a new feature.

[stefanpenner]

yes this is related. I guess I need to role the fix sooner rather then later.

[raytiley]

Duplicate is #11604 I believe, although that one is currently closed.

[stefanpenner]

I have no idea why the other one is closed. The intent of HTMLBar's props first, attrs later approach is the highest possible fidelity with the underlying DOM or WebComponent nodes. This is obviously a loss in fidelity.

In addition, this is actually just illuminating the flawed existing behaviors, and results in some other serious issues...

––––

I am about 5 failing tests away from what appears like a much better solution.

[raytiley]

I am about 5 failing tests away from what appears like a much better solution.

When are you not 5 failing tests away from a solution?

[stefanpenner]

right now. 0 failing tests, now just waiting on other things....

[rlivsey]

@raytiley ah that's why I didn't find it, thanks!

[stefanpenner]

i believe tildeio/htmlbars#374 should address this.

[rwjblue]

Fixed in 1.13.3.

[stefanpenner]

thanks for releasing :)