Gepubliceerd: Maandag 22 december 2008
Google Chrome en Microsofts Hotmail-dienst kunnen niet met elkaar overweg. Het versturen van e-mail in de nieuwe browser is onmogelijk.
Toon volledig artikel
Ik heb de blog van Google er eens op nageslagen. In dit artikel wordt gesproken over een bug in Chrome, ik vraag me af waarop dit gebaseerd is. Wat Google erover zegt is dat de oorzaak van het probleem is dat Hotmail (a) allerhande browserspecifieke dingen doet en (b) Google Chrome niet goed herkend en daardoor (c) hele verkeerde dingen naar Chrome toestuurt. De oplossing zal dus niet van Google moeten komen, en "Hotmail verslikt zich in Chrome" was dan ook een betere titel geweest voor dit artikel.
Dat verklaart ook waarom een als Safari vermomde Chrome wel goed werkt. Nu is Webkit (de basis van zowel Safari als Chrome) de eerste render-engine die is gecertificeerd als "zich aan standaarden houdend", dus ik ben bang dat de fout in dit geval bij Microsoft gezocht moet worden.
"Hotmail verslikt zich in Chrome" was dan ook een betere titel geweest voor dit artikel.
Welkom bij Webwereld. ;)
Webwereld verwelkomt Peter Koopman zou een beter titel zijn geweest...
Microsoft CEO Steve Ballmer is, once again, sending his PR minions to the ER in cardiac arrest. Apparent statements made Down Under about supporting WebKit have set off a poop storm of controversy and debate. Steve's statements, from yesterday, got taken just a wee bit out of context. But there's enough ambiguity to ask: Will Microsoft support WebKit, or won't it?
BRON: www.microsoft-w...opt_webkit.html
Nieuwe puzzel = nieuwe antwoorden... "het is groen en het zit vast.." is er ook zo één...
Plof...
Wees getroost, dat probleem komt vaker voor bij 'blinden' die op zoek zijn naar het woord van de waarheid.
Nietzsche werd lange tijd niet begrepen, zo leert de geschiedenis ons allen...
Dat weinig woorden veel kunnen zeggen is beperkt begrepen, ik had je hoger ingeschat.
Fouten maken we allemaal Peter, het is niet anders...
Plof...
Probleem is denk ik niet dat hotmail geen standaard conforme versie kan leveren want die levert het ten slotte ook aan Firefox en Safari en voorheen ook aan de Chrome beta
Het probleem lijkt me dus eerder dat Google Chrome een andere user agent identificatie heeft gegeven na de release dan tijdens de beta.
Ik weet trouwens niet of ze dat ook aangekondigd hebben.
Bijvoorbeeld de IE8 user agent string is al heel lang bekend zodat webdevelopers zich al op een nieuwe UA-string kunnen voorbereiden. Bij Chrome gaat het wat sneller en hebben webdevelopers die tijd eigenlijk nauwelijks
Developers moeten gewoon stoppen met het sniffen van user agents! Dit was ook niet nodig geweest als alle browsers zich aan de standaarden hadden gehouden. Dell heeft bijvoorbeeld switch managment software die gewoon kijk hard een melding geeft dat ik geen IE gebruik. Stel ik die UA in op IE dan werkt het gewoon 100%. Kansloos ....
Developers moeten gewoon stoppen met het sniffen van user agents! Dit was ook niet nodig geweest als alle browsers zich aan de standaarden hadden gehouden
Browsers bestaan al een jaar of 15 en er is nog nooit een browser geweest die zich aan alle standaarden heeft gehouden. Ook nu is daar nog volstrekt geen sprake van.
Sterker nog, een zeer groot deel van de websites zijn otwikkeld in een tijd dat er vrijwel geen enkele browser was de meest basic standaarden enigzins compleet hadden geimplementeerd. Het is dus niet zo gek dat in al die jaren waarin het internet enorm is geexplodeerd er enorm veel websites ontwikkeld zijn die rekening hielden met de eigenaardigheden van browsers.
Het is nu wel lekker om hard te roepen dat die websites mee het identificeren van browsers moeten stoppen maar er zit voor tientallen miljarden aan investeringen in websites. Daar gaat men niet zo maar even wat aan sleutelen.
Zeker de komende paar jaar zal dit nog een voorkomende praktijk zijn.
Het probleem is ook een beetje dat een hoop bouwers juist van de standaarden afwijken om een bepaalde browser te kunnen ondersteunen. Als iedereen zich gewoon aan de standaarden had gehouden (ik weet ook wel dat dat in de praktijk gewoon niet te doen is, maar in theorie klinkt het leuk) dan waren de bouwers van webbrowsers ook min of meer verplicht geweest de standaarden goed en volledig te implementeren.
Als ik je goed begrijp is jouw redenering dat als er maar genoeg mensen waren geweest die een website hadden gemaakt die het in geen enkele browser deed, maar wel aan de standaarden voldeed, de browser bouwers snel zouden zorgen dat wel aan de standaarden voldaan werd. Interessante gedachte, maar gaat wel een beetje voorbij aan dat je graag wilt dat je website ook daadwerkelijk door iemand te bekijken is.
Een ander punt is dat de standaarden tegenwoordig heel specifiek zijn. In de tijd van IE3, Netscape 3 was dat nog niet zo. Toen konden twee browsers allebei de standaard hanteren en toch verschillende output produceren. Verder was er toen sprake van heel veel innovatie op browsergebied en kon de standaard de wensen niet bijhouden. Als je nu kijkt, zijn we veel meer bezig met consolidatie en zijn nieuwe features nauwelijks meer interresant. In zekere zin lopen de standaarden nu voor op de praktijk in plaats van achter.
De grap is: Hoe kun je als webmaster nou weten wat standaard is als vele browsers er zich niet aan houden. Dan heb je niet bepaald een duidelijke referentie. Natuurlijk kan ik zegen dat Firefox beter is dan IE en dat Webkit zich beter aan de standaarden houdt, maar toch hebben ze allemaal op bepaalde vlaken onenigheid met elkaar en dan is het moeilijk zegen welke gelijk heeft. Chrome, Firefox, Opera, IE8beta2?
Hoe kun je als webmaster nou weten wat standaard is als vele browsers er zich niet aan houden.
Dat was in de midden jaren negentig van de vorige eeuw misschien een valide vraag, inmiddels niet meer. Het W3C is inmiddels een instituut dat alle belangrijke spelers op de browsermarkt gebruiken voor hun producten en web ontwikkelaars kunnen gebruiken om hun creaties op af te stemmen.
Daarbij moet men wel het volgende in acht nemen:
Niet elke (aanbevolen) standaard dicteert alles tot de letter, komma, punt of millimeter precies, waardoor er genoeg ruimte overblijft tot eigen interpretaties van browserbakkers (wat een reden kan zijn dat er minieme verschillen kunnen zijn in het uiteindelijke resultaat in de verschillende browsers).
Niet alles is nog een officiële standaard (en/of compleet uitgewerkt), maar wordt al wel ondersteund of ingezet.
Het is, al met al, een bewegend speelvlak. Sommige onderdelen daarvan liggen toch aardig vast en kun je gebruiken als fundament, andere onderdelen vragen wat meer flexibiliteit van een web ontwikkelaar.
en dan is het moeilijk zegen welke gelijk heeft. Chrome, Firefox, Opera, IE8beta2?
Ze hebben allemaal evenveel gelijk (zolang het geen bugs zijn die verantwoordelijk zijn voor de verschillen). Daarom is het als web ontwikkelaar belangrijk je werk altijd te testen in verschillende browsers en niet te verwachten dat je met exacte wetenschap bezig bent.
Als je altijd een zelfde resultaat wil behalen in opmaak en zo, moet je een PDF on-line zetten, wordt weleens gezegd. Webpagina's zijn nu eenmaal geen drukwerk, maar zo 'vloeibaar' als de pest en vergt het ontwikkelwerk m.b.t. de lay-out en de technische aspecten erachter daardoor een andere werkmethode en denkkader dan men wellicht gewend is in de ready-for-print-wereld.
Chrome Useragent
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.36 Safari/525.19
Safari Useragent
Mozilla/5.0 (Windows; U; Windows NT 6.0; nl-NL) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
In beide gevallen is het vrij duidelijk dat je met de Webkit engine te maken hebt.
Het lijkt me dan ook dat je daarvoor sowieso een fallback maakt.
Ziet er inderdaad niet zo heel verschillend uit qua rendering engine.
Misschien snifft hotmail niet op de rendering engine maar op het version/3.2.1 deel ???
Chrome Useragent
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.36 Safari/525.19
Safari Useragent
Mozilla/5.0 (Windows; U; Windows NT 6.0; nl-NL) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
In beide gevallen is het vrij duidelijk dat je met de Webkit engine te maken hebt.
Webkit OF APPLEwebkit...
Hint: www.botsvsbrows...0594/index.html
Plof...
Ja maar beste hAl,
Dat je aan user agent sniffing doet kan ik me voorstellen.
Dat je als zijnde MS allerhande IE-only spullen in je web-applicaties stopt ook.
Ik vind mezelf best redelijk in deze.
Als je echter een user-agent niet herkent dan behoor je gewoon terug te vallen op iets dat werkt volgens de HTML4 standaard. HTML1 gaat misschien wat ver. Dan zou zomaar kunnen blijken dat je ook geen tig user agents meer hoeft af te vangen, maar bijvoorbeeld kunt volstaan met "IE7 of hoger" = "MS Bargoens" en "Overig" = "HTML4". Dan is de wereld weer een stukje simpeler en de ontwikkelaar ook weer blij. Maar misschien ben ik naïef.
Als je je site gaat customizen voor iedere willekeurige browser die langs kan komen word je als web-developer (groot of klein) vanzelf gek en houd je het op den duur niet meer bij. Zoals hier gedemonstreerd wordt.
Dat zou je zeggen maar Microsoft doet dat dus wel en op zich best op een slimme manier: IIS rendert verschillende HTML-elementen op verschillende manieren, afhankelijk van de browser. Dus het aanpassen op de browser gebeurt slechts één keer en de webprogrammeur bouwt op een wat hoger abstractieniveau.
Dat is althans de theorie. Een andere theorie is dat beheerders van een populaire site als Hotmail concurrerende browsers opzettelijk kunnen laten struikelen. In de hoop dat mensen overschakelen naar je eigen browser.
Google laat desgevraagd weten dat er een voorlopige oplossing is. Deze is echter niet eenvoudig uit te voeren.
Zijn we al zover gezakt dat het toevoegen van een parameter aan een snelkoppeling als 'niet eenvoudig uit te voeren' moet worden betiteld?
Rechts klikken op je Chrome icoontje, eigenschappen kiezen en in doel de volgende tekst toevoegen (Dus niet vervangen):
--user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1 Safari/525.19"
Niet eenvoudig? :s
Het schaalt niet echt als je voor elke site die iets speciaals van de browser wil een aparte snelkoppeling moet maken... En zoiets werkt ook niet goed als je de browser niet start met een snelkoppeling, maar door bijv. een link in een mailprogramma te klikken. Dan moet je al in het register gaan klooien.
Opera heeft een mechanisme om automatisch een lijst met sites, waarvoor iets aan de instellingen moet worden verandert voor behoorlijke weergave, aan de browser te sturen.
En ja, ook mail.live.com staat op deze spooflijst van Opera...
Pas geleden werd aangekondigd dat ook IE8 zoiets zal doen, omdat er belangrijke sites zijn waar de verbeterde ondersteuning voor standaarden leidt tot problemen. mail.live.com zal dat wel niet nodig hebben - en gewoon zelf IE7-mode aanroepen desnoods.
Het schaalt niet echt als je voor elke site die iets speciaals van de browser wil een aparte snelkoppeling moet maken.
Dat lijkt me niet echt nodig. Ik denk dat er meer sites draaien met de aangepaste useragent string, dus totdat Microsoft en Google er uit zijn zou ik de alternatieve agent string gewoon voor alles gebruiken.
bijv. een link in een mailprogramma
Point taken. :) Daar heb je gelijk.
Zijn we al zover gezakt dat het toevoegen van een parameter aan een snelkoppeling als 'niet eenvoudig uit te voeren' moet worden betiteld?
Rechts klikken op je Chrome icoontje, eigenschappen kiezen en in doel de volgende tekst toevoegen (Dus niet vervangen):
--user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1 Safari/525.19"
Niet eenvoudig? :s
We zijn niet zover gezakt, we zijn nooit zo hoog gestegen. Dat is inderdaad voor velen te ingewikkeld. Inleven in mensen aan de onderkant van de computerkennis samenleving is niet voor velen weggelegd...
Leuk dat je dat opgemerkt hebt, ik heb ook gemerkt dat Microsoft gebruik maakt van Internet Explorer om haar MSN.com portal te promoten... :-)
Als je heel eerlijk bent, dan geef je aan dat men niet alleen reclame maakt voor Google Chrome, maar ook voor Firefox (onder W2K zelfs alleen voor Firefox). Verder geeft men OOK aan dat er een nieuwe versie van IE8 in ontwikkeling is die dan weer sneller/beter zou zijn als IE7 en geeft men aan dat er een mogelijkheid is om reeds een beta-versie van IE8 te downloaden.
Zo gek is het natuurlijk niet dat er reclame gemaakt wordt via bekende producten, zoals ik in mijn inleiding al aangaf doet Microsoft dat ook.
Overigens blijf ik het vreemd vinden dat Hotmail nog steeds op browsers aan het sniffen is en niet -zoals je zou verwachten- naar features zoekt. En zelfs al zou er een reden zijn om de User-Agent te sniffen, dan nog zou men op render engine moeten sniffen en niet - zoals nu weer blijkt op een specifieke browser...
First post, in ieder geval eerste keer dat ik op artikel hier reageer :)
Mijn firefox 3.1 beta 2 kan ook niets met hotmail, en met opera nieuwste versie is het ook giswerk, doet-ie 't wel of doet-ie 't niet. 9 op 10 keer komt het op de laatste optie neer. Wat mij betreft is Chrome dus onschuldig, en mogen de scripters van hotmail nog een keer achter hun oren krabben met hun bericht "we luisteren naar onze gebruikers en hebben hotmail nu voor u verbeterd!"
Inderdaad, soortgelijke ervaring hier. De bug zit 'm dus in Hotmail.
Zou Microsoft echt zo incompetent zijn of is dit een verwoede poging de neergang van hun browsermarktaandeel te stoppen?
Zou Microsoft echt zo incompetent zijn of is dit een verwoede poging de neergang van hun browsermarktaandeel te stoppen?
Vast een combinatie van beiden :)
Zoals al opgemerkt, dit soort browser-sniffing is waanzin. Ik gebruik Debian en dus een Firefox-fork die Iceweasel heet (lang verhaal, iets met copyrights). En "dus" waarschuwt Hotmail me vrolijk dat ik risico loop dat het niet goed werkt. Werkt altijd prima, daar niet van.
Lieve, lieve webdevvers bij MS: een browsercheck doe je op functionaliteit, niet op UA. De simpele versie:
if (document.all) { // IE
} else if (document.getElementById) { // DOM-compliant browser
} else { // iets naers met document.write?
}
Net zoals elke webdevver ter wereld tegenwoord 2 versies van z'n Ajax-initialisatie heeft: eentje met ActiveX voor IE, en eentje met XMLHTTPRequest voor de rest (en een fallback als het sowieso niet ondersteund wordt, natuurlijk).
f (document.all) { // IE
} else if (document.getElementById) { // DOM-compliant browser
} else { // iets naers met document.write?
}
De juiste volgorde is overigens anders:
if (document.getElementById) {
/* std compliant */
} else if (document.all) {
/* ie proprietair */
} else {
/* dom 0 ellende? */
}
Bij Microsoft werken ze inderdaad eerst naar IE en misschien naar andere browsers toe, maar zou moet je eigenlijk niet redeneren. Eerst de standaarden volgen (dat lijken ze zelfs bij MS te gaan doen met IE8...)
Eerst de standaarden volgen (dat lijken ze zelfs bij MS te gaan doen met IE8...)
Zal wel goed komen. :-)
IE7 is al een grote stap vooruit in dat opzicht (t.o.v. IE6), en het IEBlog laat al heel lang zien dat ze er zeker serieus mee bezig zijn. Ik heb i.i.g. meer vertrouwen in het IE-team dan dat hele Microsoft bij elkaar, zou ik haast willen zeggen. ;-)
(En dat komt van een fervent Firefox gebruiker. Maar, dat is gewoon mijn persoonlijke voorkeur.)
De juiste volgorde is overigens anders:
Plusje omdat je in theorie gelijk hebt; in de praktijk helaas niet. IE ondersteunt nl. prima document.getElementById, maar dan vang je de IE-specifieke dingen dus niet af omdat je check geen fallthrough bevat. Dan zou je dus zoiets moeten doen:
switch ((document.getElementById ? 1 : 0) | (document.all ? 2 : 0)) {
case 1:
// DOM compliant
case 3:
// IE fixes for v>=6
break;
case 2:
// IE fixes for v<6
default:
// other non-compliant fixes
}
Correcter, maar maakt de code op zich niet leesbaarder :)
Overigens is mijn favoriete strategie het setten van var isIE = false bovenaan m'n scriptje, en met conditional comments setten van de goeie IE-versie indien van toepassing. Dan hoef je in de rest van je code alleen nog maar te checken op DOM-compliancy en kun je waar nodig dingen zeggen als:
if (document.getElementById) {
// do stuff
if (isIE && isIE < 6) {
// fix stuff
}
} else {
// fallback
}
Wacht even, als je document.all gebruikt voor het sniffen naar IE dan ben je fout bezig. Wist je dat Opera ook document.all ondersteunt en true terug geeft/gaf als je if(document.all) gebruikt?
Als je if(document.all) gebruikt, dan mag je binnen dat if-blok alleen gebruik maken van document.all en NIET van andere IE-specifieke zaken. Hetzelfde geldt voor if(document.getElementById).
Mocht er toch een noodzaak zijn om niet-snifbare zaken te gebruiken die IE-specifiek zijn dan kun je net zo goed de renderengine vanuit de UA bepalen. Maar het is beter om alleen naar functionaliteit te sniffen...
Wacht even, als je document.all gebruikt voor het sniffen naar IE dan ben je fout bezig.
Ja, ik geef toe dat het een slecht voorbeeld was :) De betere methode gaf ik zelf al.
document.all is sws nogal zinloos als je ook document.getElementById hebt. Beter zou zijn if (document.all && !document.getElementById) om op hele oude IE's te checken ofzo. Of nog beter:
if (!document.getElementById) {
if (document.all) {
document.getElementById = function(id) { return document.all[id]; };
} else {
// heel erg nare code die de hele document boom recursief doorloopt ofzo
}
Lieve, lieve webdevvers bij MS: een browsercheck doe je op functionaliteit, niet op UA. De simpele versie
Functionaliteit wisselt toch per versie. Een check op functionaliteit kan ineens in een volgende versie werken in een browser maar dan nog steeds niet alle elementen in je site correct renderen.
Functionaliteit wisselt toch per versie.
Tja, maar dat doet er niet zoveel toe bij het object sniffen.
Je kijkt dan toch niet naar evt. nieuwe of veranderde features of welke versies, maar zegt eigenlijk:
Als deze techniek, dan dit voorschotelen. Als die techniek, dan dat voorschotelen. Als geen van deze technieken, dan krijgt u dit voorgeschoteld.
Een check op functionaliteit kan ineens in een volgende versie werken in een browser maar dan nog steeds niet alle elementen in je site correct renderen.
Het blijven ontwikkelen van je web site is daarom belangrijk, natuurlijk. Maar, ondertussen hou je de gebruikers (tevreden) op je site/service, dankzij de juiste sniffing-techniek, die gewoon gebruik kunnen maken van de geboden functionaliteiten van je service.
De enige die heeft gebroken met backwards compatibility, die ik uit mijn hoofd kan verzinnen, is IE8.
Probeer de UA-string van Firefox dan eens te veranderen in die van een browser die hotmail wel ondersteund. (Kan met behulp van de [url="https://addons.mozilla.org/en-US/firefox/addon/59"]User Agent Switcher extensie[/url], bijvoorbeeld.)
Ik ben benieuwd of het dan wel werkt.
Hier hetzelfde probleem met ubuntu/firefox, in hotmail kan niet getypt worden, echter als ik met de user-agent-switcher meld dat ik een firefox op XP ben is er niets aan de hand met hotmail.
Dan is het 100% duidelijk dat het geen drol met Firefox te maken heeft (en waarschijnlijk ook niet met chrome, maar dat ik nu niet testen)
MS levert gewoon brakke kode aan de combi firefox-ubuntu........
Bedankt voor het testen en de feedback, trouwens.
Even je browser's UA spoofen is voldoende, dus.
MS levert gewoon brakke kode aan de combi firefox-ubuntu........
Ze doen het niet handig, nee.
Als een browser niet herkend wordt, had men een hotmail-lite (o.i.d.) kunnen voorschotelen. Of zoiets. Maar, goed. Browser-sniffen is gewoon niet handig, zoveel is inmiddels duidelijk.
Tsja was te verwachten van microsoft. Ze kunnen al niet eens een stabiele IE uitbrengen die door de acid 2 test komt. Laat staan dat ze zelf hacks moeten toepassen voor hun eigen browsers haha.
En hotmail blokkeren van google is een goede truc!!
DIT, dit is dus een COMPATIBILITEIT probleem tussen CHROME en HOTMAIL. Niet meer en niet minder.
"Als er op de 'bouwstenen' van LEGO géén LEGO staat vermeld dan is het ook echt géén LEGO..."
Plof...
"Mecano, HET recept voor (toekomstige) Ingenieurs en Inbrekers"
Voor alle mensen die hotmail in Chrome missen:
mobiele hotmail site
(webwereld werkt overigens goed in Chrome).
Een e-mail adres dump je niet zomaar. Want velen hebben je adres en anders moet je aan iedereen vertellen dat je bij een andere e-mail boer zit.
Neu. Je exporteert de data en importeert dit in je nieuwe e-mail boer. Je laat de e-mail vervolgens forwarden (voor een bepaalde tijd) en informeert in de loop der tijd inderdaad je belangrijke contacten over je nieuwe e-mail adres. Toegeven, niet iets om in 5 minuten te bewerkstelligen. Zeker niet op Hotmail...
Gebruik gewoon Windows Live Mail op je pc. Daar stop je gewoon al je hotmail en live accounts in en hoef je het nooit meer met een browser te doen. Plus natuurlijk dat je meteen weet als je een mail ontvangt.
Naar mijn mening is Windows Live Mail 1 van de successen van microsoft, zou niet graag meer zonder willen.
Hotmail draait prima hoor onder Firefox op mijn 64bits Kubuntu 8.04 KDE 3.5 machine.
Daarbij heeft Microsoft idd ook een mobiele site.
De grote vraag is hoeveel browser specifieke code zit er in de hotmail verwerkt. En niet alleen MSIE specifieke code, maar ook voor de andere ondersteunde browsers.
Hotmail draait prima hoor onder Firefox op mijn 64bits Kubuntu 8.04 KDE 3.5 machine.
Nu wel, ja. :-)
Er is even een tijdje geweest, toen Firefox 3 net uit was en met de overgang van de nieuwe look van hotmail, dat niet alle functies werkten in Firefox. (Om dezelfde reden; browser-sniffing gone bad.)
Even afwachten hoe het zal gaan met de definitieve uitgave van Firefox 3.1...
Daarbij heeft Microsoft idd ook een mobiele site.
En voor diegene die ook Thunderbird gebruikt, kan daarvoor de WebMail extensie installeren/gebruiken.
Kun je gewoon je hotmail account beheren via Thunderbird. Is ook nog een optie.
Het is misschien onhandig dat hotmail browsersnifft maar het is zeker niet ongewoon en iedereen weet dat dat op brede schaal wordt toegepast.
Ook bij Google weten ze dat.
Het lijkt me daarom dat als Google de Chrome browser in de beta een gelijke UA-string had gegeven dat er nu vrijwel zeker geen probleem zou zijn geweest.
Als je een beta versie van je browserversie op de markt brengt die zich op een bepaalde
manier identificeert en dat als je uit beta komt toch nog even je UA string wijzigt dan vraag je om onverwachte resultaten.
Hou toch op man, lekker schijnheilig.
Het wordt op brede schaal toegepast omdat IE zich niet aan de standaarden houdt, en dit probleem was al bekend voor Linux-gebruikers met een alternatieve user-agent. Microsoft is hier zeker op de hoogte van, en al helemaal van het uitbrengen van Chrome, dus het is gewoon sabotage door non-compliance. Geheel volgens de M$-strategie, mag ik wel zeggen.
Wat nou schijnheilig.
Weten ze bij Google niet dat er tienduizenden sites zijn die op basis van de UA string content presenteren ?
Waarom in je final ineens andere UA string erin gooien ?
Misschien om dat het versienummer van je browser verandert?
Chrome 1.0.154.39
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.39 Safari/525.19
Chrome 0.4.154.18
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.4.154.18 Safari/525.19
Het spijt me wel maar voor mij blijft alleen de conclusie over dat Microsoft een hele rare check doet.
Zo te zien heeft Hotmail helemaal nooit een check aangepast voor Chrome.
Ik dacht eerst dat er bedoeld werd dat de hotmail in beta nog werkte maar nu niet meer.
Dat was blijkbaar incorrect gedacht.
Ik heb nu de blog post van Google erbij gelezen en daaruit concludeer ik eigenlijk dat Hotmail Chrome nooit heeft herkent en dat je ook al tijdens de beta een Safari UA string nodig had om bij je hotmail te komen maar dat dan hotmail dan alsnog nog correct niet werkte door andere bugs in Chrome die inmiddels in de afgelopen release van Chrome op 18 december zouden zijn op gelost.
Dus blijft het wachten op Hotmail. Slome lui daar.
Dus blijft het wachten op Hotmail. Slome lui daar.
:0)
En, indien je echt moet checken, waarom dan niet op rendering engine selecteren?
checken op de rendering engine lijk me zeker het meest zinvol
Ik kan me voorstellen dat je op een site met complexe javascript contructies op alletwee checkt.
De rendering engine voor html en CSS en de browser aanvullend voor de script engine.
checken op de rendering engine lijk me zeker het meest zinvol
Nee, dat is fout, fout en nog eens fout. Waarom? Omdat je maar aanneemt wat een browser je vertelt (en ja, dit heb ik door schade en schande geleerd). Les 1 voor elke programmeur: NEVER TRUST USER INPUT! Ook de UA-string is een vorm van user-input (je kunt hem namelijk al dan niet makkelijk aanpassen).
Of een bepaalde functie in javascript bestaat is niet te spoofen [tenzij je met een Greasemonkey-scriptje de boel moedwillig stukmaakt, maar dan moet je ook niet zeuren]. Dat IE conditional comments uitleest is niet te spoofen. Maar je stuurt nooit, nooit, nooit andere HTML naar de client op basis van UA-string. Dat gaat gewoon een keer fout (zoals nu al blijkt). Zorg dat je HTML/CSS zelf goed naar beneden schaalt, afhankelijk van hoe ver je wilt gaan met ondersteuning.
Dank je, ik las bij Xbox dat het ook niet direct een fout van MS, overal prijs je MS aan, soms tot vervelends toe, soms tegen de draad in en soms met de nodige tirades zoals nu.
Dan is het een redelijk eenvoudige conclusie, dan geeft je reactie toch meer nuance dan de stelling.
Je moet gewoon leren lezen en niet blind interpreteren.
duidelijk is dat je reactie op mijn comment echt slaat als een tang op een varken omdat je de reactie zelf niet eens leest maar gewoon blind interpreteert naar eigen believen.
Het is in de laatste week al een flink aantal keren gebeurd dat jij zaken beweert ten aanzien van reacties die er niet instaan. Pure overinterpretatie die in je hoofd zit.
Als ik schrijf dat hotmail iets niet herkent dan ga jij er blijkbaar bij denken dat omdat ik dat schrijf het wel positief voor MS moet zijn of slecht van chrome. Dat is dom want dat staat er namelijk niet. Je moet gewoon lezen wat er wel staat.
Sorry hoor hAl, maar zonder tirade.
WW artikel: Open source beleid overheid heeft impuls nodig.
hAl moet MS Office even promoten.
WW artikel: Microsoft ziet ernst in van SQL server-lek
hAl moet even positief Moonlight neer zetten
Artikel over Xbox krassen probeer je af te doen met je moet hem niet bewegen (overigens de smoes van MS)
Het lijkt dus alsof je het niet eens bewust doet als ik je tirade mag geloven. Maar het komt zo vaak voor dat ik niet eens moeite moet doen als je meer voorbeelden wil.
WW artikel: Microsoft ziet ernst in van SQL server-lek
hAl moet even positief Moonlight neer zetten
Maar daar werd ook specifiek om gevraagd volgens mij.
Laat er hier en daar wat twijfel zitten, maar meestal is deze er niet, hoe vaak is er een ODF discussie geweest over een artikel waar alleen het woord document in voor leek te komen.
Hoe vaak wordt IE 8 beta als alternatief genoemd als 7 weer eens negatief genoemd wordt, alsof er geen goede niet beta alternatieven zijn.
Hoeveel menig is er oeverloos gedram geweest, mijn mening telt en jouw mening klopt niet discussies. Vergeet niet, het zijn meningen, geen stellingen.
Neen, MS is bij hem zo aanwezig dat hij het misschien niet eens zelf ziet.
WW artikel: Open source beleid overheid heeft impuls nodig.
hAl moet MS Office even promoten
Dat was weer jou interpretatie. Het artikel ging duidelijk ook over open standaarden. In jouw reactie tav een stukje over het toepassen van open standaarden schreef ik een bericht waarin ik bijvoorbeeld OOo vaker noemde dan MS Office en dan interpreteer jij dat MS Office reclame.
En het was heel logisch dat ik OOo en MS Office gebruikte als voorbeelden voor de open standaarden discussie want daar ging het toch voornamelijk over in het afgelopen jaar.
Het zit dus volkomen in je eigen hoofd hoe jij andersmans berichten interpreteert. Je leest er volkomen overheen dat ik vaker aan OOo refereer maar reageert als een dolle op alles wat ook maar aan MS gerelateerd is. Dat bord voor je kop heb ik al eerder genoemd. Je leest en interpreteert selectief maar ziet daardoor gewoon niet meer wat er echt in mijn reacties staat.
Het trieste is nog dat eerder nog juist door jou reactie de focus van de discussie gelegd werd naar MS Office.
Lees voor de grap nog maar eens na in de discussie
webwereld.nl/co...puls-nodig.html
Zo te zien heeft Hotmail helemaal nooit een check aangepast voor Chrome.
Kan je uitleggen hoe je tot die conclusie komt? Uit de link die je mee levert haal ik het namelijk niet.
Ik refereerde eigenlijk aan de blogpost genoemd in het artikel.
Ook op andere plaatsen wordt aangegevne dat hotmail tot nu toe chrome niet herkent
Bijvoorbeeld
http://www.chromeplugins.org/
Bedankt, ik neem de beschuldiging terug. Je hebt met de laatste link inderdaad vrij overtuigend bewijs. Waarom post je die niet gewoon direct, dat vermijd een hoop discussie.
Ik vertelde het gewoon.
Je hoeft niet meteen alles in twijfel te trekken.
Het sloot ook prima aan bij de link die in het artikel trouwens werd genoemd.
De onhandige uitleg/interpretatie van Webwereld zette mij eerst op het verkeerde been.
Ik twijfel aan bijna alles waar jij een Microsoft spin aan kan geven. Het zit te vast in je natuur. Aangezien je over bugs begon waardoor Hotmail niet zou werken, sloeg bij mij deze keer foutief een spin alarm aan.
Nou, er stond toch echt in de blogpost van Google gerefereerd in het dat zij bugs in Chrome hadden weggewerkt die in hotmail een rol speelden.
Dat was dus in ieder geval evident waar.
Zo gek is het niet hoor dat een stuk software een bug heeft. Ook google kan software bouwen met bugs. Het was juist dat nu ze die bugs waardoor onder andere de hotmail pagina niet goed functioneerde uit Chrome gehaald hebben dat het extra vervelend is dat de hotmail site nog steeds Chrome niet herkent zonder kustgrepen om Chrome op safri te laten lijken.
Weten ze bij Google niet dat er tienduizenden sites zijn die op basis van de UA string content presenteren ?
Het zou me niets verbazen als er een browserspoof-knopje/functie in chrome gaat komen, trouwens. Getiteld: Make compatible!
Waarom in je final ineens andere UA string erin gooien ?
Daarom.
Hoe moet google dat trouwens doen bij een volgende alpha/beta/final? Gewoon exact dezelfde UA-string aanhouden? Als enige browserbakker in de gehele wereld? Grapjas.
Als je een beta versie van je browserversie op de markt brengt die zich op een bepaalde
manier identificeert en dat als je uit beta komt toch nog even je UA string wijzigt dan vraag je om onverwachte resultaten.
Je draait het verschrikkelijk krom om.
Als je UA-strings kunt uitlezen kun je het ook gewoon gebruiken waar het voor bedoeld is: Identificatie. (Met welke browser komen de bezoekers op mijn site.)
Als je het uitlezen van UA-strings ook nog eens het gebruikt om bepaalde content/technieken te serveren (zoals bij, kom laten we eens een voorbeeldje noemen; hotmail), dan vraag je dus om onverwachte resultaten.
Echt ongelooflijk dat men een browser ontwikkeld en hotmail 'vergeet' goed te testen...Ach er zijn maar miljoenen mensen die hotmail gebruiken, dus waar hebben we het over...
Waarom hebben alle browsers niet gewoon dezelfde interface, dat zou het wel wat gemakkelijker maken voor de webdeveloper.
Nu maak je een website en dan wordt het wel goed weergeven in ie, maar dan weer niet in firefox.
Als dit een chrome bug is, dan mogen ze ook met de snsbank bellen.
Kan geen geld overmaken met Chrome. Het transactie verzendknopje reageert niet. Op alle andere'knoppen' reageert het wel.
Andere browsers, no problemo.
Moet wel zeggen dat ik het een errug vreemde bug vind. Lijkt me toch website gebonden.
Als alle browsers zich nou eens heel goed aan de standaards zouden houden, dan zou er weinig meer gebeuren. Standaards evolueren per definitie langzaam en vrijwel alleen onder invloed van afvalligen die meer succes hebben. Vaak probeert men een standaard tot standaard te verheffen nadat de verschillen tussen de leveranciers al zo groot zijn dat het onmogelijk is voor een of meer fabrikanten om aan de standaard te voldoen zonder te breken met zijn eigen compatibiliteit.
Het zou wel mooi zijn als er zoiets zou zijn als een basisset die wel per definitie goed gerenderd wordt door iedere browser zodat je als web developer kunt kiezen om browser onafhankelijk te zijn. Dat is er ook wel nu, maar die set is wel heel erg beperkt. Waardoor vrijwel iedere webbower grijpt naar browser specifieke elementen.
Op het blog laat Google weten dat er gewerkt wordt aan een definitieve oplossing voor de bug in de browser, die officieel nog geen twee weken oud is.
Volgens mij zegt Google zelf iets heel anders:
We hope to get the issue with user agent detection resolved with Hotmail so this step isn't needed.
Ze zijn in overleg met Hotmail om het opgelost te krijgen. Erg slordig stukje journalistiek.
Ik denk dat de verwarring komt omdat Chrome wel degelijk bugs met Hotmail heeft opgelost en dat aangeeft in hun bericht.
Ze geven ook aan dat Hotmail nog steeds niet hun browser herkent en dat om de verbetering die zij nu hebben geimplementeerd te testen je nog steeds de UA string op een Safari like string moet zetten.
Ik dacht eerst dat een een herkennings issue was geintroduceerd bij de 'Final' Chome release.
Het is dus echter een herkenningsissue vanuit Hotmail dat al speelt sinds chrome is uitgebracht en daarnaast seperaat enige issue binnen Chrome tav hotmail die inmiddels zouden zijn op gelost in hun 1e correctieve release na het final gaan van Chrome.
Dus tot vorige week was trage aanpassen van Hotmail van de herkenning van Chrome minder irritant omdat Chrome toch niet goed werkte met hotmail. Nu zijn ze bij Hotmail gewoon erg sloom.
Om te kunnen reageren, dient u ingelogd te zijn.
Unified communications biedt vele voordelen, maar heeft ook specifieke uitdagingen en niet ieder project levert het verwachte ROI op.
Downloaden
1 jaar geleden: 26 mei 2011
2 jaar geleden: 26 mei 2010
14 jaar geleden: 26 mei 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, Jobworld, MacWorld, SHUTR fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
