Incorrect parsing?

Oct 5, 2009 at 3:32 AM
Edited Oct 5, 2009 at 7:59 PM

I have a page snippit that lookes like this:

<asp:LinkButton ID="Foo" runat="server" Text="< BAR" Font-Size="8" Font-Bold="true"></asp:LinkButton>

 

Without SPF, the resulting HTML is this:

<a id="Foo" href="javascript:__doPostBack('Foo',')" style="font-size:8pt;font-weight:bold;"><BAR</a>

 

With SPF, the resulting HTML is this:

<a id="Foo" href="javascript:__doPostBack('randomSTRING','RANDOMstring')" style="font-size:8pt;font-weight:bold;"><></a>

SPF appears to be mis-parsing the '<' in the string "< BAR" and then incorrectly "fixing" the HTML by replacing "BAR" with a '>'

 

 

Coordinator
Oct 5, 2009 at 1:53 PM

Can you double check the HTML snippet that you included above? Other than the two doPostBack arguments, the "With" and "Withouth" HTML fragments look identical (and I don't see "BAR" in either).

Oct 5, 2009 at 8:01 PM

Fixed.

Coordinator
Oct 6, 2009 at 4:32 AM

Interesting, I am also able to reproduce the same issue on my end.  It would appear that this is being done by the HTML Agility Pack library, which SPF uses to parse the response HTML.  I did notice that when the "<" is double encoded (i.e. &amp;lt;) the problem goes away and the link button is rendered properly. 

As a workaround, I would suggest that you double encode this character as follows:

<asp:LinkButton ID="Foo" runat="server" Text="&amp;lt; BAR" Font-Size="8" Font-Bold="true"></asp:LinkButton>

which should produce the following HTML and will render properly.

<a id="Foo" href="javascript:__doPostBack('randomSTRING','RANDOMstring')" style="font-size:8pt;font-weight:bold;">&lt; BAR</a>

Obviously this is just a workaround.  I'll need to import the latest version of HTML Agility Pack (http://www.codeplex.com/htmlagilitypack) with the next SPF build release and see if this issue still persists.  If so, perhaps a thread on their discussion board is warranted.  Let me know what you think.

Oct 6, 2009 at 5:11 AM

The workaround works for me as well, but if this is due to a bug in the upstream parser, (and it's not fixed in the latest release), then yes it should be brought up with them to fix.