Output being modified

[Chroniclemaster1]

Here's something I've never run into before. I'm outputting a string to a literal control, and the string contains several values concatenated. So far so good, I've done that plenty of times. I have an abstract class which has some basic machinery to create an XHTML tag, here's a snippet of the output code.

outputString += "<" + classTagName + getAttributes() + "/>";

In my implemented class I've defined this variable in the constructor

classTagName = "input type='radio'";

So how on earth can this produce the output...

<input ...lots of attributes... type="radio" />

The single quotes have become double quotes and the the attributes have been spliced into the middle of my string variable. Obviously, this isn't going to kill me, but I would like to know what's going on. (Before I do something that will kill my program.)

[NightStalker-DNS]

You use you are just not looking at what your browser is showing? Have you tried just writting out the string and see how it looks?

[Chroniclemaster1]

Agreed. That's the next thing to try, but I was toast last night. I've recoded this as a string literal that's just passed from the controller class back to the code behind and into the HTTP Response.


In code:
outputSelectTestsAndPagesUiOutput = "<input type='radio' id='myId' class='mighty mouse' lang='en' xml:lang='en' />";

XHTML output (as copied from view source):
<input id="myId" class="mighty mouse" xml:lang="en" lang="en" type="radio">

Further, I don't know if it will help solve the issue, but here's another interesting transformation from a string literal into XHTML output...

In code:
outputSelectTestsAndPagesUiOutput = "< id='myId' class='mighty mouse' > </ >";

XHTML output (as copied from view source):
&lt; id='myId' class='mighty mouse' &gt; <!-- -->

Any ideas what could be doing that processing? And how to control it?

[imaginekitty]

... XHTML output (as copied from view source):
&lt; id='myId' class='mighty mouse' &gt; <!-- -->

Any ideas what could be doing that processing? And how to control it?

Do you have the literal's Mode="Encode"?

[Chroniclemaster1]

I just found out what the problem is. One of the tech guys on the Wrox P2P forum suggested it. I thought he was high, but I had nothing better to test so I gave it a try and he was right. If anyone else wants to take a crack at what's processing the code after the literal is initialized, I'll wait until I log in again (or at least 24 hours) before playing spoiler.

Do you have the literal's Mode="Encode"?

This is absolutely what I thought was going on except nothing is set explicitly and I didn't do anything differently than I have for the past year, but that's not it. It's not a problem with the literal control.

[imaginekitty]

... If anyone else wants to take a crack at what's processing the code after the literal is initialized, I'll wait until I log in again (or at least 24 hours) before playing spoiler. ...

Tease!

A response filter?

[Chroniclemaster1]

Tease!

A response filter?

You know you love it.

I guess you could technically say that problem is the response is being processed or filtered, so the answer is kind of yes, but I'm not familiar with a "filter" module, so the question is still what is doing the filtering.

[imaginekitty]

You know you love it.

I guess you could technically say that problem is the response is being processed or filtered, so the answer is kind of yes, but I'm not familiar with a "filter" module, so the question is still what is doing the filtering.

OK, I'll play some more. Magic8ball says: AjaxControlToolkit

[Chroniclemaster1]

OK, I'll play some more. Magic8ball says: AjaxControlToolkit

Interesting guess, but the answer is (if anything) even weirder. It's the browser! At least that's the only operational theory I can find that jives with these test results.

There's no javascript (AJAX, jQuery, or otherwise) involved. Like you were saying, it looks like some kind of attempt at encoding, except I've never heard of a browser doing that kind of manipulation on raw XHTML before (like... ever). It's something I never even really thought about doing this kind of server side programming, but the techie at Wrox asked if it was happening cross-browser. I thought that was a ridiculous question to ask at the time, but when I went to put some test results together to show him that wasn't it...

Here's the results I came back with. In IE and Opera the output is identical (to each other, alternate versions, and the server-side literal) but in Firefox, not so much.

Code output:
outputSelectTestsAndPagesUiOutput = "<input type='radio' id='myId' class='mighty mouse' lang='en' xml:lang='en' />";

XHTML output (as copied from view source):
<input id="myId" class="mighty mouse" xml:lang="en" lang="en" type="radio"> (Firefox 2.0)
<input id="myId" class="mighty mouse" xml:lang="en" type="radio" lang="en"> (Firefox 3.6)
<input type='radio' id='myId' class='mighty mouse' lang='en' xml:lang='en' /> (Opera 9.23)
<input type='radio' id='myId' class='mighty mouse' lang='en' xml:lang='en' /> (Opera 10.6)
<input type='radio' id='myId' class='mighty mouse' lang='en' xml:lang='en' /> (IE 6.0)
<input type='radio' id='myId' class='mighty mouse' lang='en' xml:lang='en' /> (IE 8.0)


Code output:
outputSelectTestsAndPagesUiOutput = "< id='myId' class='mighty mouse' > </ >";

XHTML output (as copied from view source):
&lt; id='myId' class='mighty mouse' &gt; <!-- --> (Firefox 2.0)
&lt; id='myId' class='mighty mouse' &gt; <!-- --> (Firefox 3.6)
< id='myId' class='mighty mouse' > </ > (Opera 9.23)
< id='myId' class='mighty mouse' > </ > (Opera 10.6)
< id='myId' class='mighty mouse' > </ > (IE 6.0)
< id='myId' class='mighty mouse' > </ > (IE 8.0)

Based on those results, I don't see any way to explain it except that Firefox is manipulating the XHTML. Maybe a security feature? Still I've never heard of such a thing, and this is certainly the first time I've seen it in action where a browser receives a plain XHTML page and independently tweaks it sans JS.

[imaginekitty]

Wow. That's crazy!

I would have never guessed a browser would manipulate markup. Have you done any digging at mozilla?

[Chroniclemaster1]

Yeah, but I haven't found anything. There's lots of stuff on security and development. Lots of stuff about preventing or enabling cross-site operations, dealing with scripts especially preventing malicious scripting. However, there's nothing about "securing" XHTML. At least not that I can see. It opens interesting questions about what's going on, but at least for now, the most logical theory appears to be that Firefox is manipulating the XHTML even before we get down to the code which implements Firefox's rendering.

[imaginekitty]

Interesting.

Have you tried adding the output to a plain .html file and seeing if Firefox manipulates that markup? If it doesn't that would rule out Firefox and point to .NET serving up markup to different browsers. Do you have something like a .browsers file in the App_Browsers folder?

Does it only happen with an XHTML doctype?

[Chroniclemaster1]

Interesting.

Have you tried adding the output to a plain .html file and seeing if Firefox manipulates that markup? If it doesn't that would rule out Firefox and point to .NET serving up markup to different browsers. Do you have something like a .browsers file in the App_Browsers folder?

Does it only happen with an XHTML doctype?

Good question, which I think I've answered though not in the way I expected to. (Didn't try switching to an HTML doctype, which I will try if I, ha ha, get a chance later).

No, I don't have a .browsers file, I dropped it and my App_Browsers folder when I dropped the CSS friendly adapters. I found them noble, but insufficient for my needs. The web server control architecture is fundamentally about one thing, eliminating the need to know XHTML. For a front end designer like me, who only came to server side programming after learning XHTML, then CSS, then JS, it's a solution looking for a problem. And given that I eliminate client miscommunications by switching from comps in the sketch phase to XHTML prototypes in the design phase, the architecture just got in my way. It was never designed to render a fine-tuned prototype and doesn't have the tools for that, so finally bit the bullet and just code my UIs using old-fashioned custom OOP techniques.

It is indeed firefox. There's some kind of JS plug-in, I suspect, doing the conversion. In order to more easily grab the code I want, I typically highlight around the area and choose View Selection Source. This opens a new window entitled, DOM source of selection and this is what I've been cutting and pasting above.

To do my test I did a simple View Page Source, so I could test the exact page, as is, as static XHTML saved with a .html extension. What I immediately discovered when I went to copy the code is that viewed this way in the "Source of Mypage.aspx" window does in fact show the "correct" version of these lines.

Based on that, since we can see the original code when looking at the source for the entire page, I believe that Firefox is getting the same XHTML as all the other browsers. After that, however, it's doing some kind of DOM manipulation. To me that probably means JS, which I believe is further strengthened by the dominance of JS as the language of most of the Mozilla plug-ins that I know. This doesn't make sense behavior wise for any of the plug-ins that I have, so I would guess that it's part of the core security of the browser. Especially since it's consistent on the old 2.0 version of one computer and the new 3.6 version I have on my other. It would be interesting to see if someone gets different results though using the View Selection Source option.