Kan compatibiliteitsweergave niet verdwijnen?

Ik gebruik de flot plotbibliotheek. Het lijkt goed te werken in IE8 en IE9, maar het probleem komt in de IE9 Compatibility View - het geeft geen van de grafieken weer. Ik vermoed dat dit komt door het HTML5 canvas object dat het zwaar gebruikt, maar ik zou het mis hebben. Ik heb geprobeerd het volgende te doen:

  • Add: <meta http-equiv="X-UA-Compatible" content="IE=Edge" /> to my HTML <head></head> tag. I even tried IE=8 and IE=9 and that did not help either. My tag look like this:

    
    
    
    <meta http-equiv="X-UA-Compatible" content="IE=8" /> ... </head> <body> ... </body> </html> 
  • Because I was still seeing the problem, I added the following to my Global.asax.cs file:

    void Application_End(object sender, EventArgs e)
    {
       // Code that runs on application shutdown
        Response.Headers.Add("X-UA-Compatible", "IE=Edge");
    }
    

Ik sta nog steeds voor het probleem. De fout die ik krijg is dit:

HTML1202: http://intranetdomain/SampleProj/Default.aspx is running in Compatibility View because 'Display intranet sites in Compatibility View' is checked. 
Default.aspx
HTML1113: Document mode restart from IE7 Standards to IE9 Standards 
Default.aspx

Is er hoe dan ook om dit te doen?

EDIT: Checking my response headers, adding that line in Global.asax.cs did not add them to my headers. I wonder why.

Response Headers:

Key Value
Response    HTTP/1.1 200 OK
Cache-Control   private
Content-Type    text/html; charset=utf-8
Server  Microsoft-IIS/7.5
X-AspNet-Version    4.0.30319
X-Powered-By    ASP.NET
Date    Thu, 27 Oct 2011 20:39:55 GMT
Content-Length  29088

EDIT 2: Blijkbaar was Application_End de verkeerde gebeurtenis. In plaats daarvan injecteerde dit het element in de kop:

void Application_BeginRequest(object sender, EventArgs e)
{
    Response.Headers.Add("X-UA-Compatible", "IE=Edge");
}

Maar het probleem zelf blijft aanhouden.

16
@SliverNinja: Ja. Ik heb het als mijn eerste tag. Ook mijn vraag bijgewerkt met de exacte opmaak die ik gebruik.
toegevoegd de auteur Legend, de bron
@SliverNinja: toevoegen in Application_BeginRequest injecteerde het element in de header, maar het probleem blijft bestaan.
toegevoegd de auteur Legend, de bron
@Chris: Je had gelijk. Toevoegen aan Application_BeginRequest , ik kan de headers niet zien aan de kant van de client, maar het probleem blijft bestaan ​​:(
toegevoegd de auteur Legend, de bron
@Chris: Dat komt omdat in de methode Application_Start het respons -object nog niet beschikbaar zou zijn voor gebruik.
toegevoegd de auteur Legend, de bron
Application_End is niet de juiste gebeurtenis. Probeer PreSendRequestHeaders ( msdn.microsoft. com/en-us/library/& hellip; )
toegevoegd de auteur SliverNinja - MSFT, de bron
Zou dan volgens de populaire feedback hier moeten werken ( stackoverflow .com/vragen/637.039/& hellip; ).
toegevoegd de auteur SliverNinja - MSFT, de bron
heb je geprobeerd het toe te voegen als de eerste tag na <head> ? IE lijkt hier alleen op te reageren als het eerst voorkomt in de lijst met metatags.
toegevoegd de auteur SliverNinja - MSFT, de bron
@Legend: Ja, ik bedoelde Application_BeginRequest. Application_End wordt geactiveerd wanneer de toepassing wordt afgesloten ... Wat niets zou doen voor aanvragen die tijdens de uitvoering van de toepassing plaatsvinden.
toegevoegd de auteur Chris, de bron
Is er een reden waarom u de antwoordheader toevoegt in de methode Application_End? Zou dat niet in plaats van de Application_BeginRequest-methode moeten zijn?
toegevoegd de auteur Chris, de bron

4 antwoord

Het probleem kan te wijten zijn aan de compatibiliteitsweergave-instellingen van Internet Explorer. Als u naar het menu "Extra" gaat en vervolgens "Compatibiliteitsweergave-instellingen", zorg er dan voor dat "Intranet-sites weergeven in compatibiliteitsweergave" niet is aangevinkt. U ziet mogelijk dat IE u dwingt om een ​​compatibiliteitsweergave te maken op basis van uw hostnaam die wordt gedetecteerd als zijnde in uw intranet.

Merk op dat - afhankelijk van uw versie van IE - u wellicht op de linker Alt -toets moet drukken om de menubalk te laten verschijnen, van waaruit het menu "Tools" kan worden geopend.

28
toegevoegd
Ja. Dat is inderdaad het geval. Hoewel ik dit voor mezelf kan veranderen, probeer ik deze instelling te overschrijven (hoewel ik het niet zozeer begrijp). Ik kan deze modus zelfs niet vinden omdat deze controle: if ($ .browser.msie && parseInt ($. Browser.version)! = 9) {alert ("Not IE9!"} doet merk niet op dat IE9 in compatibiliteitsmodus staat.
toegevoegd de auteur Legend, de bron
Ik denk niet dat je die compatibiliteitsinstelling kunt overschrijven. Zie de reacties op stackoverflow.com/questions/3726357/… .
toegevoegd de auteur Jacob, de bron
Als u lokaal actief bent, zorg er dan voor dat u een 'live ogende' URL doorzoekt in uw hostbestand en dat hij denkt dat de site een internetsite is.
toegevoegd de auteur sidonaldson, de bron
Want dat is precies wat een webontwikkelaar die in/localhost/wil werken werkt - om zijn of haar werk standaard in IE7-emulatie te bekijken. Bravo, Microsoft. Ga door met het eten van lijm.
toegevoegd de auteur Imperative, de bron

U kunt compatibiliteitsinstellingen rechtstreeks op IIS instellen. Als u op de site klikt en responskoppen opent, kunt u X-UA-compatibel met een waarde van IE = X toevoegen, waarbij X uw doelversie is. U kunt dit ook op serverniveau instellen. Maar onthoud dat als u meerdere sites op dezelfde doos heeft, u daar mogelijk problemen mee hebt. Hoewel u zich op serverniveau kunt aanmelden en vervolgens de overgenomen configuratie op siteniveau kunt verwijderen.

3
toegevoegd
Dit werkte voor mij. Ik gebruik IIS Express lokaal om een ​​site met jQuery 2 te ontwikkelen. Het is niet compatibel met de IE 7-modus die IE 10 standaard voor de lokale site lijkt te gebruiken. Open het configuratiebestand% UserProfile% \ My Documents \ IISExpress \ config \ applicationhost.config en . Zie msdn.microsoft.com/en-us/ library/jj676913 (v = vs.85) .aspx
toegevoegd de auteur Cameron Taggart, de bron
Dit kan IE niet overschrijven omdat de site een intranetsite is!
toegevoegd de auteur sidonaldson, de bron

Twee jaar en twee nieuwe edities van IE later, en dit IE8-probleem veroorzaakt nog steeds problemen!

Ik vond dat voor de ASP.Net-app van ons bedrijf het toevoegen van de "X-UA-compatibel" in web.config, op de webpagina's of de code erachter absoluut geen verschil maakte.

Het enige dat voor ons werkte, was het handmatig aanvinken van het selectievakje "Intranet-sets weergeven in compatibiliteitsweergave":

Turn off Display intranet sets in Compatibility View

2
toegevoegd
Hetzelfde hier ... ik wil niet dat alle gebruikers dit selectievakje uitschakelen :(
toegevoegd de auteur Dot_NET Pro, de bron

Het rare is dat - als je de runat = "server" verwijdert, de tag meta </​​code> werkt en de knop verdwijnt. BNut het is natuurlijk niet aan te raden om de runat te verwijderen.

0
toegevoegd