Gisteren schreef ik over een paar features in Exchange 2013 EAC die niet meer werken in Chrome 37. Inmiddels zie ik ook berichten van mensen waarbij bepaalde knoppen in Exchange 2010 OWA niet meer werken, dit blijkt te herleiden naar dezelfde oorzaak. In dit artikel leg ik uit wat het probleem is, schets de context en leg uit of we hier wat aan kunnen doen.
Wat is het issue dan?
Microsoft maakt in OWA en ECP/EAC gebruik van de showModalDialog method, deze methode wordt gebruikt om een dialog box te openen met daarin een specifieke HTML-pagina. Voorbeelden van plaatsen waar deze methode gebruikt wordt zijn de From: en To: buttons in OWA 2010 en het + en potlood icoon in Exchange 2013 EAC. Het volgende scherm is een voorbeeld van een dialog box die op deze manier wordt aangeroepen:
In Chrome 37 werkt de showModalDialog method niet meer en verschijnen deze dialog boxes dus niet. Overigens raakt dit niet alleen Microsoft applicaties zoals Exchange, SharePoint en Dynamics maar ook verschillende producten van andere leveranciers en een grote hoeveelheid (interne) websites die van deze methode gebruik maken.
Waarom werkt dit niet?
De ontwikkelaars van Google Chrome hebben er voor gekozen om showModalDialog standaard uit te schakelen in Chrome 37. In een volgende release zal showModalDialog compleet verwijderd worden.
Zou het moeten werken?
Als je het aan de ontwikkelaars van Chrome vraagt dan wordt uitgelegd dat deze feature ooit in IE4 zat en sindsdien is bijgehouden in andere browsers maar eigenlijk nooit had mogen bestaan. Als je het aan Microsoft vraagt dan zullen die antwoorden dat ze Chrome 37 ondersteunen als client voor OWA in de premium versie:
Waarom is deze keuze gemaakt?
Volgens de ontwikkelaars van Blink, de rendering engine van Chromium waar ook Chrome op gebaseerd is, kost het bijhouden van deze methode erg veel moeite, de code is erg complex geworden en er zijn afhankelijkheden van andere twijfelachtige code. Verder is een kenmerk van deze methode dat hij a) een pop-up geeft, wat niet goed werkt op mobiele platformen en b) de rest van de browser bevriest zolang de pop-up actief is. Dit heeft zelfs al tot een aantal security vulnerabilities geleid.
Als deze methode maar weinig gebruikt wordt en uiteindelijk geheel uit de code verwijderd kan worden dan zou dat veel voordeel brengen voor de programmeurs.
Sinds wanneer?
Aangezien het lijkt dat de hele wereld, inclusief Microsoft, verrast is door deze aanpassing is het goed om eens naar de tijdlijn te kijken. In oktober 2013 is onder Chromium ontwikkelaars voorgesteld om een teller toe te voegen om het gebruik van showModalDialog te meten en een waarschuwing te geven aan website-ontwikkelaars. Hiermee wordt showModalDialog 'deprecated' verklaard, ofwel een feature die uitgefaseerd gaat worden. Op 1 oktober 2013 is dit voorstel verwerkt in de code en op 10 april 2010 beland in de Chrome 35 Beta. Op hetzelfde moment is aangekondigd om showModalDialog in Chrome 36 geheel te verwijderen.
Door het toevoegen van de teller werd vastgesteld dat slechts 0,006% van de pageviews deze methode gebruikt:
Voor de ontwikkelaars werd dit gezien als bevestiging dat bijna niemand dit gebruikt. In de hierop volgende discussie kwam er wel wat tegengas maar werd er vooral met het voorstel ingestemd. Ik betwijfel of iemand zich realiseert hoe groot de impact is om de functionaliteit van 0,006% van de pageviews stuk te maken, heeft iemand dat percentage omgerekend naar absoute aantallen? Is er een inventarisatie gemaakt van bekende applicaties die in deze categorie vallen om de impact beter te kunnen begrijpen?
De definitieve versie van Chrome 35 verscheen op 20 mei van dit jaar, Chrome 36 volgde al op 16 juli en Chrome 37 een maand later, op 26 augustus. In tegenstelling tot wat eerder aangekondigd was is showModalDialog in Chrome 36 nog steeds aanwezig maar in 37 is deze uitgeschakeld. In verschillende blogposts is de keuze om showModalDialog te verwijderen verder toegelicht en beargumenteerd.
Uitgeschakeld of verwijderd?
In Chrome 37 is de feature uitgeschakeld maar weer in te schakelen tot 15 mei 2015, daarna wordt de feature echt verwijderd. En hier wordt het interessant. Chrome kent een policymodel waarmee bepaalde features geconfigureerd kunnen worden, bedoeld om Chrome geschikt te maken voor de zakelijke markt. We kunnen de policy EnableDeprecatedWebPlatformFeatures gebruiken om een uitgefaseerde maar nog niet verwijderde features weer aan te zetten.
Hoe zet ik het weer aan?
Met (een elevated instance van) PowerShell zouden we dit als volgt doen:
New-Item HKLM:\SOFTWARE\Policies\Google\Chrome\EnableDeprecatedWebPlatformFeatures
Set-ItemProperty HKLM:\SOFTWARE\Policies\Google\Chrome\EnableDeprecatedWebPlatformFeatures 1 ShowModalDialog_EffectiveUntil20150430 -type string
Bij het testen van deze code bleek HKLM:\SOFTWARE\Policies\Google\Chrome op mijn computer niet te bestaan:
En ook na het handmatig toevoegen van de hyve bleek de instelling niet doorgevoerd te worden in Chrome, zo bevestigd een bezoek aan chrome://policy/.
Om te begrijpen waarom moeten we weer even terug naar het ontwikkelproces van Chrome. De policies konden nu geconfigureerd worden door middel van registry keys of een GPO policy template. Nadat Chrome registry keys ging gebruiken om de configuratie te managen bleek al snel dat deze registry settings ook aangepast konden worden door andere programma's, denk bijvoorbeeld aan malware. Als reactie ging Chrome 28 de registry keys negeren en kon alleen nog het GPO template gebruikt worden om Chrome te configureren. Wat uiteraard tot veel klachten leidde van beheerders die geen AD gebruiken, geen GPO's of beheer standaard op basis van registry keys uitvoeren.
De verandering in Chrome 28 werden nu deels teruggedraaid en vanaf Chrome 35 worden de registry keys ook weer gebruikt, alleen als de computer lid is van een Active Directory domein.
Wat nu dan?
Beheerders van werkplekken in een AD domein kunnen de registry key of het GPO template gebruiken. Voor losstaande werkplekken kan de GPO template ook in de Loacal Group Policy (gpedit.msc) gelezen worden:
- Download de policy templates hier.
- Open gpedit.msc en ga naar "Computer Configuration" -> rechtsklik "Administrative Templates" -> "Add/Remove templates" -> klik "Add..." -> selecteer "windows/adm/en-US/chrome.adm" uit de policy_templates.zip download
- In "Computer Configuration" -> "Administrative Templates" -> "Classic Administrative Templates" -> "Google" -> "Google Chrome" configureer je nu de policy settings.
- Open nu Chrome en ga naar chrome://policy/, hier moet de aangepaste policy nu zichtbaar zijn.
Ontwikkelaars van website zullen alle instances van showModalDialog moeten vervangen door een alternatief.
Wat vinden we hier van?
Het hele verhaal roept de vraag op in hoeverre Chrome klaar is voor de zakelijke markt. De razendsnelle ontwikkelingscyclus van dit open-source project verrast beheerders en ontwikkelaars van websites door features uit te schakelen. Hetzelfde geldt voor het uitschakelen van het beheer door middel van registry keys, zoiets kun je niet doen zonder de zakelijke markt zorgvuldig te informeren en een alternatief te bieden.
Maar ook de afwezigheid van Microsoft in deze discussie valt op. Bij mijn onderzoek viel me op dat er uitgebreide discussies plaatsvinden en hebben gevonden binnen de Chromium, Chrome en Opera communities maar ook bij Mozilla Firefox waar de zelfde discussie speelt. Is er dan geen enkele developer bij Microsoft geweest die zich realiseerde dat zijn applicatie volop gebruik maakt van deze feature? En dat juist nu Microsoft OWA duidelijk positioneert als de primaire client om te werken met e-mail.
Zakelijke klanten zullen zich afhankelijk van hun contract tot Premier Support richten of een case openen via de reguliere supportkanalen. Gebruiker van Office 365, ofwel hun beheerders, kunnen een support request openen In het Office 365 admin center. Ik verwacht een bericht op het Exchange Team Blog één dezer dagen en volg de discussies in de communities met veel interesse.
No comments:
Post a Comment