Part 3 of my continuing coverage of my hybrid all code Visual Studio / no code SharePoint Designer team's adventure discussed a weird workflow issue. Basically, an element in our master page was not playing nicely with workflow; errors were thrown upon loading the workflow association page (CstWrkflIP.aspx). Once I figured out the fix, I celebrated by leaving the office in a good mood for a change.

However, the next day, still glowing from my workflow salvation, it turned out that this triumph only unearthed the next layer of problems. This time, the culprit was blank association pages. No more errors? Win. But empty divs making a hollow skeleton out of my master page? Fail; worse than having errors. What was weird was the fact that there were indeed several divs visible in IE's developer tools, all properly nested as though they were framing up the InfoPath Forms Services content of the association form.

So when I say "blank," I mean, to a user, there's no content between the header and footer of the master page; to a developer, however, something much more interesting was happening. Normally, blank pages caused by hardcore ASP.NET errors simply render opening and closing body tags. The underlying issue is usually something like a configuration problem, or malformed HTML, or missing file references. But the workflow engine in this situation was trying really hard to render something, but just couldn't.

After digging a bit through the master page code and what I saw in the IE dev tools, I determined that it was indeed the InfoPath form that refused to render; everything else was fine. So the first thought I had was to check on the InfoPath Forms Services settings in central admin. Well, it was one of those situations when, unfortunately, everything was fine. I went back to the browser (which was laden with tabs to central admin, site settings, workflow settings, and so on) and wandered around the generated "blank" HTML a bit more. Everything seemed in order. I refreshed the page. Suddenly, without any particular logical reason why, I saw an InfoPath form looking back at me, seemingly saying: "Yeah, I'm here now. So what?"

I felt a rush of bliss combined with annoyance, because I didn't actually fix anything. What if it broke again? I wouldn't have a procedure to re-repair it. Quickly, both feelings gave way to despair: I was on a stale tab displaying my local environment (which always worked), not the one with my development environment (which never worked). I had refreshed the wrong tab! Ugh. I went back to the dev browser window, refreshed it, and sure enough, was met with the same blank stare.

But the fact that I had a working environment side-by-side with a broken one meant that I had a great opportunity for a differential diagnosis. Inspecting the HTML of the correct page had all the same divs as the other; they simply had content. I dug and dug. No results. Just when I was about to preemptively abandon this idea before the hierarchy of div tags drove me insane to the point where I'd visualize them becoming sentient and forming a div monster, jumping off the page, and attacking me, I found this in the broken page's rendered markup:

NO SCRIPT! Why did InfoPath Forms Services think that JavaScript was disabled? Or was this the handling for a deeper error? Binging this yielded, again, no results. What were the other factors? The developer of the workflows told me that everything worked fine when using the default out-of-the-box v4.master master page (which was the whole reason for the previous post in this series). Taking that under advisement, I diffed the JavaScript includes and inline code.

The only difference was that the functioning page had two references to a "blank.js" file with the SharePoint "rev" querystring added. Both files had the same, meaningless (at least to me and InfoPath) code (which, in the actual file, was minimized). Okay bad attitude: I'm sure this file is meaningful to something somewhere, but not in the context of making Forms Services render on the SharePoint workflow association page. Here's what they looked like:

Dead end: everything else seemed to match. With nowhere else to turn, I opened two instances of SharePoint Designer: one for my local environment and one for the problematic development server. We had recently completed a deployment, so both master pages should have been identical. However, I noticed that the dev file had one additional line. Hmm. What could have changed? I know that my no-coders use SharePoint Designer on the server to develop and tweak some things, but the check-in time of the file was from when we commented out the offending line of code from Part 3's fix.

So I went to the location of the file that contained this control, and, my friends, there it was: SharePoint Designer barfed a bunch of crazy markup after the control, but within the comment. Now, this content is technically commented out, so it didn't affect the page appearance to the end user; the presence of that HTML in the browser, however, was enough to really piss off Forms Services. The following noise was is three attributes, "__designer:Preview," "__designer:Values," and "__designer:Templates" that SharePoint Designer added to the end of the commented out control. Here's what it looks like:

__designer:Preview="<div id="SRSB"> <div id="ctl00_ctl08"><input name="ctl00$ctl08$ctl00" type="hidden" value="http://ymca.local" /><table class="ms-sbtable ms-sbtable-ex s4-search" cellpadding="0" cellspacing="0" border="0"><tr class="ms-sbrow"><td class="ms-sbscopes ms-sbcell"><select name="ctl00$ctl08$SBScopesDDL" id="ctl00_ctl08_SBScopesDDL" title="Search Scope" class="ms-sbscopes"> <option value="This Site">This Site: Exchange</option></select></td><td class="ms-sbcell"><input name="ctl00$ctl08$InputKeywords" type="text" maxlength="200" id="ctl00_ctl08_InputKeywords" accesskey="S" title="Search..." class="ms-sbplain" alt="Search..." onkeypress="javascript: return OSBEK(event);" style="width:170px;" /></td><td class="ms-sbgo ms-sbcell"><a id="ctl00_ctl08_go" title="Search"><img title="Search" onmouseover="this.src='\u002f_layouts\u002fimages\u002fgosearchhover15.png'" onmouseout="this.src='\u002f_layouts\u002fimages\u002fgosearch15.png'" class="srch-gosearchimg" alt="Search" src="/_layouts/images/gosearch15.png" style="border-width:0px;" /></a></td><td class="ms-sbLastcell"></td></tr></table></div></div>" __designer:Values="<P N='ID' T='DelegateControl4' /><P N='ControlId' T='SmallSearchInputBox' /><P N='Version' T='4' /><P N='Page' ID='1' /><P N='TemplateControl' ID='2' /><P N='AppRelativeTemplateSourceDirectory' R='-1' />"

I'm not even daring myself to try and decipher what this might be doing. I tried replacing the ASP.NET "server side" comments (<% -- --%>) with HTML "client side" comments (<!-- -->) and ended up with the same situation. Talking with one of my no-coders, this has apparently been an issue since the FrontPage days! Either way, the solution I came up with was to simply not comment out server controls, delete them instead, and make a note of it in a change log proper. Now this isn't to say that comments don't work at all in SharePoint Designer; you can place text safely inside HTML comment blocks.

So that demystifies the disappearing InfoPath Forms Services forms in SharePoint workflow association pages. Be careful, as always, in SharePoint Designer, and have fun with workflows!