Kan compatibiliteitsweergave niet verdwijnen?

Question

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

toegevoegd 27 oktober 2011 op 11:33 de auteur Legend bewerkt 27 oktober 2011 op 11:53

Bekeken: 1

de bron

ro ru fr es pt de hi bn ar uz be tr

@SliverNinja: Ja. Ik heb het als mijn eerste tag. Ook mijn vraag bijgewerkt met de exacte opmaak die ik gebruik.

toegevoegd 27 oktober 2011 op 11:38, de auteur Legend, de bron

@SliverNinja: toevoegen in Application_BeginRequest injecteerde het element in de header, maar het probleem blijft bestaan.

toegevoegd 27 oktober 2011 op 11:52, 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 27 oktober 2011 op 11:52, 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 27 oktober 2011 op 11:46, de auteur Legend, de bron

Application_End is niet de juiste gebeurtenis. Probeer PreSendRequestHeaders ( msdn.microsoft. com/en-us/library/& hellip; )

toegevoegd 27 oktober 2011 op 11:46, de auteur SliverNinja - MSFT, de bron

Zou dan volgens de populaire feedback hier moeten werken ( stackoverflow .com/vragen/637.039/& hellip; ).

toegevoegd 27 oktober 2011 op 11:43, 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 27 oktober 2011 op 11:36, 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 27 oktober 2011 op 11:48, 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 27 oktober 2011 op 11:44, 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 28 oktober 2011 op 12:22 de auteur Jacob

de bron

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 28 oktober 2011 op 12:32, de auteur Legend, de bron

Ik denk niet dat je die compatibiliteitsinstelling kunt overschrijven. Zie de reacties op stackoverflow.com/questions/3726357/… .

toegevoegd 28 oktober 2011 op 01:29, de auteur Jacob, de bron

teelahti.fi/blog/&ellell; Dit is een zeer nuttige tip waarmee ik het compatibiliteitsprobleem van mijn interne server heb opgelost. Ik heb al je oplossingen daarvoor geprobeerd.

toegevoegd 18 augustus 2016 op 01:29, de auteur GeorgiG, 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 27 november 2012 op 01:15, 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 18 december 2014 op 11:36, de auteur Imperative, de bron

de auteur Alex Nelsone · Answer 1 · 2012-04-03T09:51Z

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 03 april 2012 op 09:51 de auteur Alex Nelsone

de bron

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 26 mei 2013 op 08:29, de auteur Cameron Taggart, de bron

Dit kan IE niet overschrijven omdat de site een intranetsite is!

toegevoegd 27 november 2012 op 01:14, de auteur sidonaldson, de bron

de auteur Mike Gledhill · Answer 2 · 2014-02-13T11:23Z

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

de auteur Oshrib · Answer 3 · 2011-11-21T04:41Z

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.