Ember templates not properly preserving white space in Ember 1.8.0-beta 5

[bravo585]

After upgrading from 1.7.0 to Ember 1.8.0 beta 5, this snippet is no longer outputting the proper white space:

{{#if filterUser}}
    {{filterUser.firstName}} {{filterUser.lastName}}
{{else}}
    All users
{{/if}}

If filterUser is "John" and "Doe", it will output "JohnDoe", when it should be "John Doe". If I used the computed property {{filterUser.fullName}} instead, it would properly display the white space "John Doe".

[rwjblue]

Seems to work properly: http://emberjs.jsbin.com/rwjblue/88/edit

Can you provide a failing test or JSBin demonstrating the problem?

[mixonic]

@bravo585 please provide some more information if this is still occurring. A specific browser?

[bravo585]

I'm using the latest version of Chrome (Version 38.0.2125.104) on a Mac. I would like to provide more detail, but I'm not sure how to isolate the problem, because it's only happening in one part of my template. I am not styling the view in any way, or doing anything weird with the CSS (like letter-spacing: 0).

[mixonic]

As we cannot seem to recreate this I'm going to close it. @bravo585 if we are breaking whitespace it would definitely be a bug. I just need more to go on for debugging.

[herom]

I updated my project to use Ember 1.8.0 today and I'm, too, seeing the issue of breaking "white space"s within templates.

@mixonic It seems that this issue is only present if you work with values which are resolved after the DOM was rendered (see my jsbin example)

My system: Windows 8.1, Chrome 38.0.2125.104 m

I'd vote for reopening this issue as this really seems like a bug to me! /cc @rwjblue (I updated your previous jsbin example too)

[mixonic]

Demonstrating the difference between initially and late rendered content with whitespace between:

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

Definitely a bug. Thanks much for the repro @herom!

[herom]

you're welcom @mixonic 😃 - I just updated your jsbin (you had a little typo) to make it work as a whole 😸

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

[mixonic]

This is a bug in Chrome's rendering engine :-(

The blank text node is still present between the two names, it is simply not rendered. Firefox does not exhibit this bug.

[herom]

omg! Yes, I can confirm this - tried it on the following browsers with only seeing this "bug" in latest Chrome.

Windows 8.1 64bit:

• Firefox (latest)
• IE11
• Chrome (failing!)

Mac OSX:

• Safari

[mixonic]

Bug at Chrome: https://code.google.com/p/chromium/issues/detail?id=428313

[herom]

Following the bug at Chrome - seems they're moving forward on solving this issue. Thanks a lot @mixonic! 👍 😃

[mixonic]

I'm going to close this issues as a #wontfix, but a little context:

Kris has been working on a refactoring of morph (the library that uses blank text nodes and triggers this bug). The refactor will land with two things to help address this:

• Instead of two blank text nodes bounding content, there will just be a single node when possible. This will lessen the chance for this error.
• When content is blank, currently two blank text nodes are present. Instead, we plan to change this to a single comment node. This will again dramatically lessen the chance of this occurring.

This refactor will land in 1.9 or 1.10, but putting into 1.8.1 or another point release is too risky. Ember will address this in an upcoming major release, and hopefully Chrome will have a real fix in an upcoming stable.

[mixonic]

This upstream issue for this has been addressed, and the fix should be included with Chrome 41 (stable on April 3rd).

[herom]

thanks a lot @mixonic - I got the notifications from the chromium board too 👍

[diogomafra]

I think there is still a problem related to white spaces.

White spaces between ember components aren't preserved. I tested in Chrome, Firefox and Safari, the behaviour is the same in all of them.

Ember 1.10
http://emberjs.jsbin.com/mazakewela/1/edit

Ember beta
http://emberjs.jsbin.com/jivusamuwu/1/edit

Ember canary
http://emberjs.jsbin.com/yuvaqoweqa/1/edit

---

[mixonic]

Seems like last summer there was a regression in Chrome that re-introduced this issue https://bugs.chromium.org/p/chromium/issues/detail?id=428313