{{bind-attr}} in 1.10.0 inserting attributes with falsy values

[jaswilli]

If {{bind-attr}} has an attribute with a falsy value, the attribute will get inserted in the element tag with the stringified version of its value, e.g.:

<img {{bind-attr src=propDoesNotExist}} alt="an image" /> will be rendered as: <img src="undefined" alt="an image" />

Here's a jsbin reproduction: http://emberjs.jsbin.com/rulehe/1/edit?html,output

Pre-1.10.0 the rendered output would be: <img alt="an image" />

Here's a jsbin with 1.9.1: http://emberjs.jsbin.com/miwola/1/edit?html,output

/cc @rwjblue

[mixonic]

We're going to consider this a regression, and include a fix in 1.10.1.

The new attributes rules are "prop-first". So <img src={{someUndefined}}> will run img.src = undefined. Browsers process this and internally set "undefined" as a string. We're going to keep this behavior in the new bindings. It this, however useless, consistent with how all attrs are handled in the new world.

In the case of bind-attr, we don't want to break semver. I'll work up a patch that removes src when the value is undefined.

[jaswilli]

Awesome, thanks for the quick response.

So when we switch to 1.11 binding syntax (attr={{prop}}) we'll have to account for null/undefined on our own (with conditionals or ensuring properties default to '')?

That works for me, just want to clarify so I can have it on my radar when the time comes to upgrade. 😄

[rwjblue]

So when we switch to 1.11 binding syntax (attr={{prop}}) we'll have to account for null/undefined on our own (with conditionals or ensuring properties default to '')?

Yes, that is the plan.

[mixonic]

In this specific scenario (src), the best pattern seems to be using an interpolated version of the value:

<img src="{{doesNotExist}}" alt="image">

http://emberjs.jsbin.com/tudaqegaxi/1/edit?html,js,output

The value interpolation occurs with join, and join converts undefined into nothing, so the attr value when the raw value is undefined is a blank string.

[jaswilli]

Excellent. Thank you both and congrats on shipping HTMLBars!

[typeoneerror]

I'm experiencing a similar issue with images where setting a value to null, I see chrome try to load

Resource interpreted as Image but transferred with MIME type text/html: "http://localhost:4200/null".

Is this a similar issue?

{{#if withImage}}
  <div class="current-image">
    <img {{bind-attr src=value}} alt="">
  </div>
{{/if}}

If value is initially null, it doesn't try to load the image, but when I update the model (to delete the image ,making value null) it's bound to, withImage is false, <img> is not in the DOM but it still makes a call to that null URL.

What am I doing wrong?

[mixonic]

@typeoneerror can you attempt a reproduction in a jsbin?

The fact that the URL is /null is definitely related and fixed in #10398 and should be in 1.10.1.

The fact that the URL is getting loaded at all seems suspect though. And un-related to anything in this ticket.

[typeoneerror]

@mixonic not with any real reliability. jsbin seems to forward "null url request" to http://null.jsbin.com/null so tough to repro. I'm guessing it's a "Chrome" thing and I've just forward-proofed current code for 1.10.1. Thanks!