CSS written in page header

Aug 21, 2007 at 3:20 PM
The menu and treeview controls are writing some style elements to the page header. It's driving me mad! I'm trying to find the method to override in my Menu control adapter to control this behavior, but I simply can't locate it. Reflector isn't helping either (i'm probably looking in the wrong place).

How can I adjust the menu and treeview control adapters to prevent this output from being written?

<style type="text/css">
.ctl00ctl00LeftSidebarWirePlaceholderLeftSidebarNavigationPlaceholderTreeView1_0 { text-decoration:none; }
.ctl00ctl00PageHeadingNavigationPlaceholderheadernav0 { background-color:white;visibility:hidden;display:none;position:absolute;left:0px;top:0px; }
.ctl00ctl00PageHeadingNavigationPlaceholderheadernav1 { text-decoration:none; }
.ctl00ctl00PageHeadingNavigationPlaceholderheadernav2 { }


Where is this coming from? All help is greatly appreciated,

Aug 22, 2007 at 3:12 PM
Have you tried digging through the source code (http://www.codeplex.com/cssfriendly/SourceControl/ListDownloadableCommits.aspx) to find where this is happening? It'd probably be easier to search the code than searching with Reflector.
Aug 22, 2007 at 3:34 PM
I'm not sure I get what you mean? I visited the link, but i'm not sure what to look for? The styling is being added by the menu and treeview controls, not the adapters (I think). So I would have to resort to reflector, or am I missing something here?

bdemarzo wrote:
Have you tried digging through the source code (http://www.codeplex.com/cssfriendly/SourceControl/ListDownloadableCommits.aspx) to find where this is happening? It'd probably be easier to search the code than searching with Reflector.

Aug 25, 2007 at 3:36 PM
Did you solve problem?
Aug 27, 2007 at 10:25 AM
Nope. Not Yet. I've spend quite some time trying to fix this and now I'm kinda waiting for someone to reply who has already solved this. I can't believe nobody has taken the effort to remove there styling rules from the header! When I fix this one way or the other, i'll be sure to post a follow-up here.

dmrev wrote:
Did you solve problem?

Sep 11, 2007 at 5:57 PM

you can use the following setting in your .browser file to clear this up:
<capability name="supportsCss" value="false" />

Sep 12, 2007 at 3:26 AM

Have a look at Issue #2714, it may be a good idea to post a fix for that item, containing your updated .browser file.
I have tested it in IE6 / 7. Firefox 2 and Opera 9 and it works.


Sep 12, 2007 at 3:19 PM
Edited Sep 12, 2007 at 3:23 PM
I've just tested the fix posted with issue #2714 and will be applying it shortly. If someone wants to adapt the techniques to the TreeViewAdapter, feel free -- and send us a patch. :)
Sep 13, 2007 at 5:28 AM
Edited Sep 13, 2007 at 5:31 AM
I've discovered a problem with this approach:

I'm using site24x7.com (www.site24x7.com) to track the heartbeat of the web site (every 5 minutes), and it throws the following exception every time it pings our default page, which contains an adapted Menu control:

Exception information:
Exception type: System.NullReferenceException
Exception message: Object reference not set to an instance of an object.

Thread information:
Stack trace: at CSSFriendly.MenuAdapter.OnPreRender(EventArgs e)
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

I haven't been able to replicate the conditions where this is happening...I guess that using a real browser, as you do when debugging, just doesn't work...

I think that should be a way to define the site24x7 service properties in the .browser file, but is it feasible to use this approach knowing that would be impossible to configure all the potential tracking services that are around?

Maybe somebody else has a better idea here :)


Sep 13, 2007 at 9:27 AM
Mm,. I'm not entirely sure as to what you mean. The page you refer to appears to be rendering, but a ping surely won't cause this, so I'm guessing the health check requests the page?

You could probable config this using the browser file as well, by checking the User Agent or maybe the Http Request method?

<userAgent match="regular expression"
nonMatch="regular expression" />
<header match="regular expression"
name="header name"
nonMatch="regular expression" />
<capability match="regular expression"
name="capability name"
nonMatch="regular expression" />

(or isn't this what you mean?)

Sep 13, 2007 at 11:22 AM
Rinze, sorry if I haven't been clear enough before, but, to clarify, the fact is that our web site is being monitored by an utility offered by a company called Site24x7.
What this utility does is described in details here: http://site24x7.com/web-site-availability.html#websiteavailability, but, basically, it sends out HTTP requests at regular intervals to a site (every 5 minutes in our case) , checking if the site is accessible or not, so you are indeed right when you say that the utility requests the page.

Something in that HTTP request is causing the exception I posted before, and, as I said in my previous post, I think that, even if there is a way to configure the browswer file (which for sure there is), this solution may only work for this particular "health check" utility and not for others, and I guess that there is a lot of people out there using these kind of things.

That's why I believe that the code itself should be smart enough to avoid throwing an exception in these cases, but, as I couldn't find a way to test and debug it (there is no way I can build our live site with debug symbols and breakpoints! :) ), I can't really propose a better solution.

I hope this helps to make things more clear and to try to find a solution,


Sep 14, 2007 at 2:45 AM
Is there any way for you to post a copy of the HTTP request sent to your server by site24x7.com? Or, can you find the IIS log file entry corresponding to the request (so we can see at least some request and response info)?

I am going to change the code from this:

ArrayList selectorStyles = (ArrayList)GetPrivateField(Page.Header.StyleSheet, "_selectorStyles");

to this:

ArrayList selectorStyles = GetPrivateField(Page.Header.StyleSheet, "_selectorStyles") as ArrayList;
if (selectorStyles != null)

Let me know if that fixes it (checked in with the latest release).

I would make an alternate suggestion... You can create a separate ASPX page with a non-public URL purely there to respond to the site24x7 ping. Why let them request a whole web page that has to be rendered? Just create a simple ASPX page, perhaps one that does one quick smoke test to confirm that your site is available (without any real UI rendering), and just display a simple HTML page that just says "OK". At the least, this will also save a (probably miniscule) amount of request processing on your web server; at the most, it will avoid the problem you're having.
Sep 14, 2007 at 3:57 AM
Edited Sep 14, 2007 at 5:03 AM

Before digging into the IIS log trying to look for HTTP requests, I decided to test the new code you posted using a non public site of ours and it works ok, the problem is gone.
After that, I updated the .dll on our live site and it also works, so I think the issue is resolved.

Also thanks for your suggestion, very appropriate indeed.


Sep 14, 2007 at 10:56 AM
It appears two solutions to the problem are being discussed here (as one). Is it true that the code sniplet using reflection is causing the Health monitoring problem (or in combination with the browser solution maybe)?

If it is configurable one could argue that the code sniplet might be removed from the project.

Sep 14, 2007 at 12:04 PM
Glad it fixed the issue, Rasetti. I should have made the null checks in the original code -- my bad for that.

Rinze -- I doubt reflection is causing the problem. Most likely the problem was a result of the base OnPreRender not setting anything in the header in certain situations (perhaps due to a BrowserCompatibility check noticing that the requester didn't support CSS, so no styles were applied in the HTML?). The original code didn't do proper null-checking against objects. Putting that code in (as it is now) should address both issues -- the original issue, and the NullReferenceException issue.