8

I'm having (yet another) strange problem with IIS. When viewing an ASPX page I've designed on my local machine by browsing to http://localhost/page.aspx the page looks as expected (and looks the same in IE, Firefox and Chrome. If I change localhost to my_hostname the page is rendered with a disabled vertical scroll bar.

The behavior was first noticed when I published my site to our live server and saw the same discrepancy. After beating my head against the wall I tried what I described above and was able to duplicate my "problem". So with that, I turn to you guys.

This wouldn't really be an issue (save for the cross-browser inconsistency) except that this screws up an "absolute"ly positioned <div> moving it partway off the screen instead of being centered like it should be (and is when viewed any other way except in IE when the address is anything but localhost).


As another test I added a new aspx page to my project and didn't add or change any of the default code. If I browse to the page using localhost there is no scrollbar. If I browse to the page using my_hostname the scrollbar is there. Whatever the difference is it's making IE's processing of CSS get screwed up, to the point where at first everything works the same in all browsers I'm testing in, and afterwards IE just makes up its own rules. This is incredibly frustrating and I'm really hoping I'm just doing something wrong and it's not an inherent problem.

1
  • 1
    I've been able to work around the CSS problem by moving my <div> out of the block that it was in and setting a negative margin. Not a graceful fix by any means, but such is life when ensuring cross-browser compatibility. It would still be nice to figure out why it's so different.
    – maik
    May 17, 2010 at 21:16

7 Answers 7

9

I know this is an old thread, but I just hit the same problem. If you are using IE8, the issue may be its Compatibility View. By default, sites in your local intranet - but NOT localhost - are rendered in IE7 compatibility view. More info here:

http://msdn.microsoft.com/en-us/library/cc288325%28VS.85%29.aspx

Unfortunately, that doesn't help get rid of the disabled scrollbar, but it does explain the discrepancy.

2
  • That's excellent. Thanks for finding and posting the insight into the issue.
    – maik
    Oct 29, 2010 at 18:58
  • 1
    It seems that IE9 does that as well. In Page > Compatibility View Settings dialog, uncheck "Display intranet sites in Compatibility View" and it'll render like it does on localhost.
    – Mike Caron
    Jan 17, 2013 at 18:49
7

The problem resides in the IE8 compatability view settings. By default, intranet sites (your server) are displayed in compatibility view. To override this behaviour you should add the following code to your code behind of your aspx page.

protected override void OnPreInit(EventArgs e) {
    Response.AddHeader("X-UA-Compatible", "IE=8");       

    base.OnPreInit(e);
}

It worked for me.

4
  • This goes right along with the compatibility stuff Claire mentioned above. Thanks for this answer!
    – maik
    Mar 17, 2011 at 16:42
  • 1
    haha I just got this problem, and I was heading here to put a post thinking "people is gonna think I am insane". Thanks a million! Sep 6, 2011 at 15:04
  • Alternately, you can add Response.AppendHeader("X-UA-Compatible", "IE=8"); to the Page_Load method in your Site.master.cs file. Jun 18, 2012 at 16:02
  • +1 This solution helped me to solved my same issue, awesome!!
    – Somebody
    Oct 2, 2012 at 13:16
2

In IE9, sites running on localhost are automatically rendered in Compability Mode. To change this (default) behaviour, do this:

  1. If not activiated, activate the toolbar Command
  2. Click Page > Settings for Compabilitymode
  3. Uncheck "Display intranetsites in compabilitymode"
0
1

Here's a post on StackOverflow about this

basically change the top of your HTML Layout or MasterPage(after the <%@...%>) to:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
1
  • This was a huge help!
    – KFP
    Sep 20, 2016 at 18:38
0

CSS shouldn't be affected by the URL. Any chance you have hidden text with the URL somewhere in the body that is causing it to shift? If you view the source of the file in both situations using a tool like http://www.quickdiff.com/, is there anything different between them?

5
  • That's the exact thought I had, which is why the problem appears to defy logic. The only thing I can come up with is that IIS is doing something special based on whether the request is coming from localhost or not. If I use localhost, 127.0.01, my IPv4 address or IPv6 address it renders the same (without scrollbar, etc.). If I use my computer's hostname or access it from another computer it renders with the scrollbar. I did initially examine the source with my eyes and didn't see any differences, and just verified that using quickdiff.com. <3 IIS :(
    – maik
    May 20, 2010 at 15:21
  • Definitely strange. How about a quickdiff on the css files? The other thing to check is firebug or fiddler2 to see if the headers are different. That will show what IIS is sending in the headers. May 20, 2010 at 16:55
  • Part of my debugging was moving what little CSS I had into the aspx file instead, so there's nothing special going on in that department. I'll check out Fiddler and see if I can see any differences.
    – maik
    May 20, 2010 at 20:32
  • Fiddler shows differences in the request and response headers. It doesn't look like anything spectacular, but maybe IE is making a rendering decision based on something there... In the request headers, the only difference is that in the my_hostname request headers, the Authorization header comes before the Host header while it's the opposite in the localhost request. In the response headers Persistent-Auth is set to false in my_hostname and true in localhost. The encoded token in WWW-Authenticate is also significantly longer in my_hostname than localhost, but the method is still Negotiate.
    – maik
    May 20, 2010 at 20:45
  • Any chance that in IE the site is set to a different zone? i.e. with one URL it's trusted and with another it's not? That would only affect IE though. May 24, 2010 at 13:12
0

The fix that @Claire applies to IE 11 as well. I was having issues where css was not being applied when accessing the site via the host name of the server, but localhost displayed fine.

To Fix:

Internet Options -> Uncheck Display intranet sites in Compatibility View

I'm not sure why localhost is not considered an intranet site though.

-1

Just to state I was having a similar issue as the OP and applying the code Serj Sagan suggested to my site master page but changed IE=Edge to IE=11, now when published it all displays as it should.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .