Beware: usage of ImageButton can cause a 401 NotAuthorized in external facing site

In one of our custom webparts we are using the ASP.NET ImageButton class. Instead of setting the image-source via the ImageUrl property, we specify the image via CSS. All works fine. That is, until we "got anonymous". Suddenly when browsing to a page with our WebPart on it, the (acceptance test) end-user was confronted with the IE loginbox. Via Fiddler (how I love this http debugging tool) I quickly detected the indirect cause: IE issued an HTTP GET for the URL of the Pages document library. In an authenticated mode this will pass unnoticed. But for an anonymous user the particular HTTP GET will result in a 401 NotAuthorized on trying to directly access the Pages folder URL.

So the next question was what caused the browser to issue this request for the Pages URL? Well, this was the direct result of our on intention lack of setting the ImageUrl property, in favor of flexible CSS specification. The resulting HTML is then something like:

<input type="image" name=" ... " class="ImgClass" src="" ... />

IE (6) browsers interpretate the empty image-src attribute as referring to the relative root of the webpage. In our case with the WebPart placed on a publishing page, this translates to a request for the Pages folder URL. FireFox and Chrome do not exhibit this behavior, they simple ignore the empty source attribute as it should. The solution for preventing IE to request the NotAuthorized Pages URL is to set a non-empty value for the ImageUrl property. It’s not even required to point to an existent image file. In that case the HTTP request will silently result in a 404 NotFound HTTP response. And since the image is set via CSS, the visual effect in the UI remains unnoticed for the end-user. I dislike polluting the HTTP transfer between browser and server with requests which are known before to fail. Therefore I point to ImageUrl to the current and available image-file. Via CSS it is then still possible to later flexible modify the displayed image.

InfoPath embedded via XMLFormView conflicts in IE with CSS relative positioning

You can apply the out-of-the-box XMLFormView webpart to embed an InfoPath form within a SharePoint page. This way, the form displays as a visual integrated part within the SharePoint application, maintaining for the user the full application context (branding, navigation menu's). However, upon doing this (after applying the required infrastructure initialization steps, see this whitepaper), I continuously encounter a runtime Javascript eror when browsing the page in Internet Explorer. The error occurs in INC\Core.js in the ErrorVisualization_ComputeAbsoluteLeft function, used to position an error asterix within the form. Within this method, the DOM-tree is traversed up to the HTML-root. At least that is the intention, but somehow this goes wrong with IE; and the OOTB script is not made robust. This article gives more background details.

So, the problem cause is known. What about the resolution? I don't intend to sacrifice the correct CSS handling, just because IE doesn't handle it well. I see multiple options:

1. Making the HTML robust by wrapping the relative positioned DIV within an absolute positioned Body-container
2. Runtime overloading the OOTB ErrorVisualization_ComputeAbsoluteLeft function to fix it for IE behaviour
3. Use the PageViewer webpart iso XMLFormView to embed the InfoPath form
4. Inspect the Core.js code, and find a proper, and more localized solution

Your guess is right, I applied the latter. It appears that although the runtime errors occurs within the ErrorVisualization_ComputeAbsoluteLeft function, the solution can be found within the invoked helper ErrorVisualization_IsPositionCausingElement function. That function returns true if the inspected style object has its overflow property set, and in that case the loop within ErrorVisualization_ComputeAbsoluteLeft stops. The solution is therefore to assign an overflow setting to a proper container element of the XmlFormView. Since CSS styles are applied afterwards, it's not possible to assign this property via CSS. Options are to either place the style inline, or to add it via code - before the ErrorVisualization_ComputeAbsoluteLeft will be invoked. I applied the last. Rationale for this is that I only want to apply the IE-hack / resolution when it is needed. That is, when an XmlFormView is rendered within either IE 6 or 7. Inline style does not allow me to that, javascript does:

<script type="text/javascript">
function fixInfoPathFormView()
{
  /*@cc_on
  @if (@_jscript_version <= 5.7)
  var objFormView = document.all["__XmlFormView"];
  if (objFormView != null)
  {
    var objFormViewContainer = document.all["wrap-center"];
    if (objFormViewContainer.style != null && objFormViewContainer.style.overflow == "") objFormViewContainer.style.overflow = "auto";
  }
  /*@end
  @*/
}
</script>

<UPDATE>The above workaround is dependent on the installation of SharePoint SP2 in your environment. Prior SP2, the ErrorVisualization_ComputeAbsoluteLeft function does not check via the ErrorVisualization_IsPositionCausingElement function; but just tries to traverse the offsetParent hierarchy until reaching the document.body object. Remedie then to avoid the runtime error is option 1: set the position of the document.body container to static.</UPDATE>