`HtmlLocalizer` and `ViewLocalizer` mishandle arguments; pass `IHtmlContent` values to HTML encoder

[dougbu]

MVC has moved away from bogus ToString overrides but the HtmlLocalizer implementation has not reacted to this change. The result is twofold:

• Many IHtmlContent values display their type names when used as IHtmlLocalizer.Html() or IViewLocalizer.Html() arguments. For example this occurs with view component results e.g. @Localizer.Html("Hello {0}!", Component.Invoke("CurrentUser")).
• Arguments that are already HTML encoded and avoid the above issue are double-encoded. This occurs with HtmlString values passed as arguments to IHtmlLocalizer.Html() or IViewLocalizer.Html() e.g. @Localizer.Html("Not that {0}!", new HtmlString("<input>")).

[dougbu]

The issue here is likely the lack of IHtmlContent special-casing anywhere in HtmlLocalizer, especially line 268.

[Eilon]

Can you clarify the scenario that doesn't work? What's broken?

[dougbu]

Pretty much any argument implementing IHtmlContent won't work as expected. E.g.

• @Localizer.Html("Hello {0}!", Component.Invoke("CurrentUser")) generates Hello Microsoft.AspNet.Mvc.ViewFeatures.StringCollectionTextWriter+StringCollectionTextWriterContent!
• @Localizer.Html("Not that {0}!", new HtmlString("<input>")) generates Not that <input>!.

In the above examples, Localizer is an injected IViewLocalizer. No matching resource but that's not relevant in this issue.

[Eilon]

Well, @Localizer.Html("Hello {0}!", Component.Invoke("CurrentUser")) isn't even a thing. Not sure why anyone would even expect that to work (regardless of whether it should work).

But the second example looks legit and should work.

[rynowak]

Load balancing for RC2

[rynowak]

a555446