Indented elements (Haml) cause spaces before non-first line of confirmation message

[henrik]

I tend to specify confirmation messages in two "paragraphs", with the second one providing details.

If I do something like

= button_to("Foo", "/url", :confirm => "Really?\n\nThis cannot be undone.")

in Haml, the resulting HTML will be indented, so attr('data-confirm') will really be something like

"Really?\n    \n    This cannot be undone."

At least in Chrome on OS X, the extra spaces show in the dialog and look bad.

In non-UJS Rails, this worked as expected.

I tried with ERB and that worked as expected. I tried using find_and_preserve in Haml but wasn't able to get rid of the extra whitespace that way. And either way, since a lot of people use Haml with Rails, it probably makes sense to make it work without extra effort there.

The attached fix gets rid of the extra whitespace before popping up the confirmation. Another solution could be to make Rails store literal \n characters and then replace those on the JavaScript end.

[mislav]

Interesting. Never knew Haml does this (but I never used newlines in attributes either). This should be submitted as bug in Haml, too, to see what Nathan thinks about it—while whitespace around HTML nodes is mostly insignificant, content in attributes shouldn't be messed with.

In the meantime I'll still pull this change because it's seems harmless enough. I can't imagine who would want leading whitespace in confirmation messages.

[henrik]

Mislav, thank you. I mentioned this issue to Nathan on Twitter (@nex3) in case he wants to chime in.

[henrik]

One use case I can think of for leading whitespace in messages would be something like

"Here is a list:
    * bullet"

But that seems pretty unlikely, so perhaps this solution is good enough.

[mislav]

If someone wants to heavily style their javascript alert() messages, they're doing it wrong.

[JangoSteve]

This looks like a haml bug for the reasons illustrated below. However, in order to get it to work, you just need to use haml's preserve filter on your confirm message. This fixes the problem:

= button_to("Foo", "/url", :confirm => preserve("Really?\n\nThis cannot be undone."))

Now we don't need to make jquery-ujs forcefully modify attributes on the off-chance that the attribute was mistakenly modified by haml.

To illustrate, it's happening because haml apparently indents the source code after it renders the newlines. So, if you have:

<div>

hi
</div>

Haml then adds two spaces to every nested line inside the div, including blank lines, so you end up with (+ represents a space):

<div>
++
++hi
</div>

Of course your newlines are rendered in the source like:

<div>
<input data-confirm="Really?

This cannot be undone."...
</div>

Which becomes:

<div>
++<input data-confirm="Really?
++
++This cannot be undone."...
</div>

So haml is adding two spaces to every line, even though the one line is both blank and actually in the middle of an attribute's string value. This definitely should be reported as a bug to haml, because it's literally modifying the value of an attribute.

[henrik]

JangoSteve, thank you! I tried find_and_preserve around the helper, but I wasn't aware you could do it the way you describe.

Reported to Haml: https://github.com/nex3/haml/issues/356

And I agree that jquery-ujs shouldn't workaround this now that your preserve solution is known, and the issue has been reported to Haml.

[JangoSteve]

Awesome, I'm sure this would bite me eventually. Glad to hear.

[mislav]

Closing this as wontfix then. Thanks for the research on this, guys