Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Experimentele aanpassing van stabiele Chrome veroorzaakt problemen bij bedrijven

Een test van een experimentele aanpassing in de stabiele versie van de Chrome-browser heeft deze week tot veel klachten van gebruikers in zakelijke omgevingen met Terminal Server geleid. De aanpassing resulteerde in white screens of death bij actieve tabs.

Honderden gebruikers klagen op onder andere bugs.chromium en op de support-pagina van Chrome over de gevolgen van de aanpassing. Daarbij roepen ze het Chrome-team op om deze terug te draaien, iets wat de ontwikkelaars inmiddels gedaan lijken te hebben. De problemen begonnen woensdag. Systeembeheerder kregen te maken met gebruikers die op Chrome 'witte schermen' kregen op actieve tabs, waarbij die tabs niet meer reageerden.

Het probleem deed zich voor in zakelijke remote desktop-omgevingen met Terminal Server en Citrix. Daaronder vallen bijvoorbeeld callcenters en uit de reacties blijkt dat niet alleen kleine bedrijven, maar ook ondernemingen met honderden en duizenden callcentermedewerkers getroffen zijn. Als een gebruiker zijn systeem op slot zette met Win + L, konden andere gebruikers van de server te maken krijgen met witte schermen en vastlopende tabs waardoor niet verder gewerkt kon worden. Herstarten van de browser of Windows weer ontgrendelen verhielp het probleem, maar het kostte werknemers en it-afdelingen veel tijd, is de klacht.

De oorzaak is te herleiden tot een experimentele functie die het Chrome-team naar de stabiele versie bracht om meer feedback te verkrijgen. "Het experiment is ongeveer vijf maanden in bèta geweest. Het werd dinsdagochtend geactiveerd en gepushed naar stable, dus versie 77 en 78. Voor die tijd was het actief voor 1 procent van de Chrome 77- en 78-gebruikers zonder meldingen van problemen", meldt David Bienvenu van het Chrome-ontwikkelteam.

De experimentele functie betrof WebContents Occlusion. Deze functie zorgt ervoor dat actieve tabs minder resources vergen als gebruikers er een ander actief venster overheen plaatsen. Het gedrag van de tabs wordt dan vergelijkbaar met inactieve of geminimaliseerde tabs, om accuduur te besparen.

Door Olaf van Miltenburg

Nieuwscoördinator

15-11-2019 • 12:02

165 Linkedin

Submitter: domantia

Reacties (165)

Wijzig sortering
Gisteren kregen wij op kantoor ook klachten over witte schermen in Chrome en dat het bij sommige opeens weer ging werken. Was geen touw aan vast te knopen wat het probleem veroorzaakte en waarom het bij sommige opeens weer ging doen. Later dus geleerd dat het door het locken van een sessie op de RDS omgeving kwam. Ondertussen de meeste gebruikers gemigreerd naar Firefox. Je kan makkelijk alle gegevens van Chrome importeren (bookmarks, cookies, wachtwoorden, geschiedenis) dus onze gebruikers waren redelijk snel weer functioneel.

Vandaag heb ik mij wat verder ingelezen in waarom dit gebeurt. De functie die ze hebben gemaakt om resources te sparen, kijkt of er een venster over Chrome heen staat. Dat kan dus ook het lock scherm zijn. Maar, het kijkt niet naar de processen van de gebruiker zelf, maar naar alle processen op het systeem (immers, het lockscherm wordt niet door de gebruiker uitgevoerd, maar door system). Het is zeer kwalijk dat ze hier überhaupt toegang toe hebben (staat en locatie) van alle processen op het systeem. Dit zou dus betekenen dat je in een proces van een andere gebruiker zaken kan doen zonder dat je er feitelijk de rechten voor zou hebben.

Google heeft deze feature wel leuk 5 maanden getest, maar er is geen duidelijk bericht naar buiten geweest hierover. Er zijn dus mensen die tegen problemen aan zijn gelopen, niet alleen die via een RDS omgeving werken maar ook op een PC als enige gebruiker, en nooit aan een of andere vage experimentele optie denken.

De manier hoe Google hier mee om gaat vind ik echt heel kwalijk. In het verleden had je ook een flag om wachtwoorden te kunnen exporteren en importeren. Als je Chrome al langer hebt draaien en die flag ooit eens hebt aangepast van de default waarde, heb je 'm nog. Nieuwe gebruikers met een nieuw profiel hebben dit niet meer. Als je dus denkt om je Chrome profiel te wissen, veel oudere flags kan je niet meer wijzigen, simpelweg omdat deze zijn verwijdert.

Het hele idee van dit soort experimentele zaken hoort IMO niet in een stabiele release van een browser. De gebruiker gaat naar Opties/Voorkeuren en past daar zaken aan naar wat ze willen. Obscure flags die gedrag veroorzaakt dat nergens in die opties/voorkeuren is te vinden horen er niet te zijn. Maak het een duidelijke optie of maak het gewoon niet.
Ik wil daar nog even aan toevoegen dat er hier nog een ander probleem speelt, namelijk het feit dat Google schijnbaar de settings van afstand aan kan passen (anders dan door middel van een update) én inzicht wil hebben in je systeemprocessen. Energiebesparing m’n r**t, ik ken Google langer dan vandaag dus dat wordt gebruikt om je nóg beter “van dienst te zijn” met gerichte reclame (ben je gamer of niet (bijvoorbeeld Steam, UPlay of Origin), gebruikt nog Office, OneDrive of DropBox (Google biedt dan bijvoorbeeld het eigen alternatief vaker aan, eventueel zelfs gericht korting kunnen aanbieden) en wat al niet meer). Dat lijkt me een zeer ongewenste situatie.

Andersom moet Microsoft eens haast gaan maken met het sandboxen van élk programma op Windows. Want uiteindelijk is het natuurlijk het beste als de mogelijkheid gewoon helemaal niet bestaat.
Windows Sandbox maakt dat mogelijk en Edge (oud+nieuw) ondersteund WDAG (Windows Defender Application Guard). Welke (web)apps via Hyper-V in een container draaien.

UWP sandboxed applicaties ook standaard. Maar het is vrijwel onmogelijk dit te realiseren voor elke applicatie die op de Win32 API draait, wat voornamelijk komt dankzij legacy en developers die zich niet aan guidelines houden of meuk in elkaar hakselen. Juist door die Win32 legacy is de Windows Sandbox redelijk omslachtig door als het ware een snapshot van je Windows installatie te draaien.
Enorm fijne bug dit.
Speelt sinds woensdagochtend, klanten bleven maar bellen om aan te geven dat hun chrome chrashed.
Heeft anderhalve dag gekost voordat het duidelijk was wat de oorzaak was.

Inmiddels hebben wij het voor onze klanten gefixt door de config aan te passen.
Wij hebben hiervoor dit script gemaakt die runt bij inloggen van de gebruiker.
https://gist.github.com/k...fa1f6a474662e7e52568f985b
Deze had ik inderdaad ook gezien, echter hebben wij het gefixt om Chrome te starten met —disable-backgrounding-occluded-windows
Dat is inderdaad ook een oplossing maar dat werkt niet zo goed als je het domeinbreed wil toepassen.
Door middel van het script lost het zich op bij iedereen, ook als chrome wordt opgestart door het openen van een linkje uit outlook bijvoorbeeld.

De commandline optie wordt namelijk niet onthouden de volgende keer dat chrome opstart, de config aanpassen wel.
Ja, iedere omgeving is natuurlijk anders en wij gebruiken het namelijk i.c.m. RES en hierdoor zal die er altijd in blijven staan, omdat de snelkoppeling is aangepast.
In dat geval zal het aanpassen van de snelkoppeling ook wel goed werken (en een stuk sneller uitgerold dan een scripts)

Puur uit nieuwsgierigheid, werkt dit dan ook als een gebruiker op een linkje klikt in de mail, of een html bestand opent voordat chrome al open staat?
Yep, bij RES (nu Ivanti) kun je ervoor kiezen om het proces te laten intercepten. Dus als je dan een linkje klikt start de RES snelkoppeling met alle settings die je daaraan hebt toegevoegd.

Het werkt overigens niet altijd goed, bij sommige applicaties veroorzaakt het problemen en/of conflicten en moet je het uitschakelen maar over het algemeen doet het wat het moet doen.
Wat ik zelf even niet begrijp, hoe komt het dat deze functie ineens "aan" staat?
Ik heb geen ervaring met beheer van Chrome in een enterprise omgeving(wij gebruiken Firefox), maar jullie hebben zelf toch ook een update gepushed neem ik aan?
Ik heb hier niks geupdate en heb zelfs GPOs aan staan die auto updates en communicatie met Google uitschakelt maar toch hadden wij er ook last van (v76).

Blijkbaar wordt er toch nog steeds naar huis gebeld om bepaalde settings op te halen. Ik zou daar toch wel meer van willen weten.
Leg eens uit wat je hiermee bedoeld?

Vind jij het normaal dat een bedrijf als Google(en dit is even belangrijk) ondanks dat alle "Google Cloud en connect" services via policies keihard zijn uitgeschakeld toch op afstand beheer kan doen over browsers in een zakelijke en afgeschermde omgeving?
Automatische updates is wel het laatste wat je wilt in een bedrijfsomgeving.
Precies. Je moest eens weten hoeveel mensen denken dat het beheren van dit soort omgevingen hetzelfde is als je PC thuis. Wij hebben ooit een situatie gehad dat onze NetApp vol liep. Management wilde niet dat wij quota's zouden toepassen, maar we kregen ook geen budget voor uitbreiding. Dan krijg je boze gebruikers die zeggen dat we maar ff een USB schijfje bij de Mediamarkt moesten halen om de storage uit te breiden. |:(
Of het wel of niet praktisch/wenselijk is om zaken automatisch te laten updaten in een zakelijke omgeving hangt helemaal af van de situatie.
Zit je lekker met je laptopje de hele dag te vroeten in Office 365: lekker de boel laten updaten.
Is er echter een enorm bedrijfskritische applicatie(die natuurlijk over het algemeen redelijk waardeloos geprogrammeerd zijn :) ) die gewoon ten aller tijden moet doen: dan moet er strak gemanaged worden. Dat is een business uitgangspunt. Denk je nu echt dat systeembeheerders het zo leuk vinden en graag tijd willen stoppen in het steeds maar testen en uitrollen van nieuwe browserversies?

[Reactie gewijzigd door YoMarK op 15 november 2019 16:27]

Wij testen nieuwe browser versies netjes. Of we er zin hebben doet er niet toe. Waar we nog minder zin in hebben is dat een belangrijke applicatie op zijn gat gaat en we krom komen te liggen van de support calls. Of erger, dat het security issues veroorzaakt en gevoelige data op straat komt te liggen.

In dit geval ook, we hadden Chrome niet geupdate, toch begon het raar te doen. Mogen we het geluk hebben dat maar een fractie van de medewerkers vrijwillig Chrome gebruikt. Maar we hebben ook webapps die enkel in Chrome werken.

@RoelRoel De webapps mogen dan wel gaar zijn, daar ontkom je ook niet altijd aan door een gelimiteerd budget, tijdsperiode, legacy of dat je duizenden applicaties hebt in je organisatie.
Same here. Sterker nog, om precies deze reden heb ik mijn Citrix servers nu op PVS draaien. Elke nieuwe versie van een golden image test ik uitgebreid en dan nog rol ik het niet meteen naar al mijn servers uit. Je kan immers niet alles testen en mocht er dan toch een probleem zijn dan kan ik eenvoudig de toegang tot de gepatchte servers uitzetten. Niet dat dat veel voorkomt, maar op een omgeving met honderden gebruikers kan je niet voorzichtig genoeg zijn.

Wij hebben ook meerdere webbased pakketten draaien en de meeste worden niet zo vaak geupdate of zijn legacy systemen. Daar kan je niets aan veranderen, sommigen kosten een ton per jaar aan licenties en updates en het installeren van een simpele update is een project an sich. Dat samen met het eeuwige snijden in budgetten helpt niet. Je moet er een beetje creatief mee om gaan om het allemaal werkbaar te houden.
Wat O365 betreft zeker, maar je weet als dat op z'n gat ligt of stuk is dat miljoenen gebruikers er last van hebben en dat MS wel gaat rennen.

Op de één of andere manier accepteren gebruikers het ook meer als een cloud dienst eruit ligt, waar bij on prem altijd flink wordt gescholden.
Nee, dit gebeurde ook bij bestaande installaties. Je hoefde er helemaal niets voor uit te rollen.

Van de ene op de andere dag stond opeens die setting aan, doordat Google dat heeft aangepast. Blijkbaar via een soort 'call home'-systeem die nieuwe settings ophaalt.

[Reactie gewijzigd door wildhagen op 15 november 2019 13:34]

Ongelofelijk. Dat Google op afstand browsers kan besturen klinkt bij mij als een nog veel groter potentieel probleem dan een paar tabs die het af en toe niet doen. Neem aan dat deze functionaliteit(weet iemand hoe dit precies heet?) ook uit te schakelen valt?
Wij gebruiken als standaard browser hier Firefox ESR, en ik mag hopen dat dit soort grapjes daar niet in zetten verwerkt.
Inderdaad hier maak ik me ook nogal zorgen over, als iemand weet hoe dit uit te schakelen is zou ik het graag horen.

Ik heb al een GPO: Disable synchronization of data with Google.

Auto update staat ook uit en alle scheduled tasks en services van Google zijn ook uitgeschakeld.
Ongelofelijk. Dat Google op afstand browsers kan besturen klinkt bij mij als een nog veel groter potentieel probleem dan een paar tabs die het af en toe niet doen. Neem aan dat deze functionaliteit(weet iemand hoe dit precies heet?) ook uit te schakelen valt?
Wij gebruiken als standaard browser hier Firefox ESR, en ik mag hopen dat dit soort grapjes daar niet in zetten verwerkt.
Niet browsers, maar Chromium browser van Google.

Het meest simpele is dit uit te schakelen door Chrome browser te deïnstalleren en gebruik te maken van alternatieven (bij voorkeur die niet gebruik maken van Chromium).

Zoals Metieske hogerop in dit draadje aangeeft hebben zij alles omgezet naar FireFox. Dat zou dus een prima oplossing zijn. In ieder geval totdat Mozilla het in het hoofd haalt ook zoiets te gaan doen...
Zelfde hier, het was even zoeken inderdaad. Vreemde manier van testen van Google

Vreemder nog was het moment van de White screen, NL als een willekeurige gebruiker zijn sessie locked, dan gaan alle Chrome tabs van de gebruikers op wit.

[Reactie gewijzigd door gabba25 op 15 november 2019 12:40]

Klopt, dat is ook de reden dat het zo lang duurde voordat we erachter kwamen wat het probleem was.
Voor ons gevoel deed het probleem zich namelijk "volledig willekeurig" voor.
Vreemde manier van testen van Google
"Fail fast, fail often", agile development...
En dat is nou juist NIET wat "fail fast, fail often" betekent.

Agile development betekent NIET dat je buggy code mag afleveren.
Het betekent NIET dat je productie omgevingen mag verstoren.

Het concept van Agile is dat je elke sprint werkende code aflevert van hoge kwaliteit.

Het concept van "fail fast, fail often" is dat je in een vroeg stadium feedback van je klant krijgt of de functionaliteit die je aan het bouwen bent wel voldoet aan hun wensen. En dat je niet één keer feedback vraagt, maar continu feedback vraagt.
Zodat je niet na een jaar een product aflevert dat niet (meer) voldoet aan de wensen.
Het probleem doet zich voor als iemand op de terminal server de sessie locked.
Wat dus erg willekeurig is. Ook hebben we getest met portable versies van een oudere versie van chrome en hierin deed het probleem zich ook ineens voor. Waardoor we de focus hebben vergroot en niet alleen meer naar chrome zijn gaan kijken maar ook naar andere aspecten binnen het netwerk.
We hebben hier het probleem ook en zoek het maar uit dat Google zonder opgave even de config van je bedrijf gaat zitten aanpassen.

Want het lijkt zich volledig willekeurig voor te doen en er is geen update uitgevoerd. Google heeft ons ook niet geïnformeerd.

"Oh ja natuurlijk checken we dagelijks even elke flag."
Achteraf is het meestal iets "simpels". Maar dat is natuurlijk niet het geval als je het probleem aan het onderzoeken bent. Dit is zo'n probleem waarvan je niet zomaar de oorzaak achter vindt als je niet weet waar je moet zoeken.
Wij hebben hier ook veel last van gehad..

Wat mist in het artikel is dat Google dit dus op hun backend kan doen.. zonder dat de client geupdate word en zonder dat de sysadmins het weten.

Deze wijziging had ook effect op MS egde Chromium beta . Dat betekend dus dat Google het gedrag van Egde Chromium kan beïnvloeden en dat MS dus niet in control is wat er allemaal met hun browser gebeurd.

ik vind dat zeer verontrustend..
Verrek, dit is ook doorgevoerd op alle browsers die Chromium gebruiken? Dat ze het bij hun eigen browser doen vind ik al ernstig...

[Reactie gewijzigd door Tikal op 15 november 2019 22:22]

Klopt, Chromium-based browsers zijn door Google ook aangepast met die setting. Inclusief Edge Chromium RC, die opeens ook die setting aan had staan.
De oorzaak is te herleiden tot een experimentele functie die het Chrome-team naar de stabiele versie bracht om meer feedback te verkrijgen.
Dat is niet de definitie die ik bij een 'stabiele versie' zou gebruiken. Misschien is het een idee om een (enterprise beheerde) opt-in/out aan te bieden voor dit soort zaken, tot zover dat er nog niet is?

[Reactie gewijzigd door The Zep Man op 15 november 2019 12:04]

Als 't 5 maanden in beta is geweest vind ik de beslissing om 't uit te rollen wel gerechtvaardigd hoor.
Niet als het nog als 'experimentele functie' is geoormerkt.
Maar dat is dus onzinnig van Chrome.

Je bedenkt een functie, probeert hebt enkele maanden uit in bèta’s , hebt het al in twee reguliere versies opgenomen,

en nadat het geactiveerd wordt en ineens een berg problemen krijgt ga je je verbergen achter termen als ‘experiment’ die helemaal niet meer van toepassing mogen zijn in dat stadia.


Ik zou me schamen als Google zijnde.
Je hebt een fout gemaakt, pak de verantwoordelijkheid en los het op.
Het besef lijkt niet helemaal gedaald te zijn bij google dat chrome wordt gebruikt voor onder andere werk maar ook bankzaken en andere essentiële prive-zaken en dat Google met chrome in veel landen een monopolie heeft.
Ik zou me schamen als Google zijnde.
Ik zou me alleen schamen omdat ze dit een experimentele functie noemen. Bugs vind je door te testen. Dit is uitgebreid getest. Helaas blijken hun testgebruikers geen gedeelde Citrix-servers te gebruiken. Daar kunnen ze iets van leren, door bijvoorbeeld een paar grote bedrijven te overtuigen in een tweede of derde testring plaats te nemen.
Als je vind dat je je voor iedere fout in het leven moet schamen ga je het niet ver schoppen.
Dit is uitgebreid getest. Helaas blijken hun testgebruikers geen gedeelde Citrix-servers te gebruiken.
Conclusie; dit is niet uitgebreid getest wanneer je naar de userbase en usecases kijkt.
Ja want iedereen gebruikt Citrix uiteraard ... Ok dit is een "standaard" omgeving binnen de bedrijfswereld. Maar hoeveel % van de bedrijven maken gebruik van Citrix. Google zal gerust wel wat meer teams hebben om dingen testen dan de meeste bedrijven. En na dit fiasco denk ik wel dat ze standaard ook dingen op Citrix zullen testen. Maar of dit voorheen al het gevolg was, is een goeie vraag en dat kan je niet weten. Maar elke mogelijk omgeving alles testen, lijkt mij onbegonnen. Ik heb zelf zo al een paar dingen als "experimental" live gezet. Je kan testen en testen, en op een gegeven moment stop het echt wel. Je kan uiteraard altijd kiezen voor een select publiek, maar je kan het ook gewoon meteen live zetten. Dit kan goed uitdraaien en er kan zich nog een probleem voordoen. Maar om eerlijk te zijn hoeveel % van het gebruik van Chrome zou op een Citrix server zijn ? Zou dit meer dan 1% zijn ?
Maar om eerlijk te zijn hoeveel % van het gebruik van Chrome zou op een Citrix server zijn ? Zou dit meer dan 1% zijn ?
Ook al is dat slechts 1% dan praat je nog over een behoorlijk groot aantal gedupeerde gebruikers welke zich in zakelijke omgevingen bevinden waar de impact hoog is en waar terugval op een andere browser niet altijd direct mogelijk is.

Het betreft overigens niet alleen Citrix systemen maar ook Terminal Server / RDS waardoor het aantal getroffen gebruikers nog groter is.
Ja 1% is 1% ben ik mee akkoord. Maar nogmaals ik zou wel eens willen weten hoeveel % van het gebruik van chrome komt van citrix/terminal server. Maar zelfs Terminal Server+Citrix, zou dit echt meer dan 1% halen ? En ja dat zijn nog altijd in getallen grote cijfers. Maar 1% (most likely minder) is 1 op 100
En dan is er nog de configuratie van die servers. Je kan onmogelijk een team full time zetten om elke mogelijke settng + chrome te controleren bij een wijziging. Ga jij aan een manager uitleggen, ja maar ik wil een full team elke keer er een wijziging is om alle mogelijke combinaties van instellingen met Citrix/Terminal server ... Denk niet dat er velen gaan zeggen, doe maar rustig.


Ik weet dat dit niet leuk is als je afhangt van een 3de partij en dat je niets weet van wijzigingen. Zo sta je altijd voor voldongen feiten. Maak ik ook regelmatig mee ... Ik heb ooit op 31 december om 15u nog de vraag gekregen om de tomtom connectie te updaten, want die werkte niet meer. De gps in de ambulance kreeg van onze applicatie niet meer automatisch het adres doorgegeven. Hier ben je al over mensenlevens aan het spreken. Maar TomTom had toen een update gedaan ergens in het weekend, waar wij dus niks van wisten ... En het was ook niet dat er een nieuwe versie bij ons beschikbaar was. Ik heb dit gelukkig zeer vlug kunnen fixen. Maar het is nu eenmaal zo. Als je webapps maakt, sta je ook dikwijls voor voldongen feiten, van mmm dat werkt niet meer op deze manier. Het is bijna onmogelijk om elk scenario te bedenken en constant alles te testen.

Nu on the other hand veel software houdt geen rekening met Citrix/Terminstal Server en dergelijke. Heb dikwijls genoeg fucnties kunnen aanpassen omdat het toch net niet werkte met Citrix en/of Terminal Server.
On the other hand, als je zo afhankelijk bent van een browser. Dan kan je ook kijken naar een fall back, wat kan je tegenhouden om bijvoorbeeld als fall back geen firefox te voorzien ?
Erger nog dat google dit schijnbaar gepushed heeft terwijl dat al helemaal niet zal mogen als de beheerder automagische updates via de policy al heeft uitgezet. Ik wil wel even het fijne weten hiervan.
en dat Google met chrome in veel landen een monopolie heeft.
Chrome heeft helemaal nergens een monopolie. Je hebt alleen een monopolie als je klanten geen keuze hebben en er geen alternatieven zijn. Bij Windows kun je in sommige gevallen spreken van een monopolie, namelijk in de context van het draaien van Windows software (wine is meestal geen optie). Maar een browser kun je simpelweg vervangen door een andere. IE zou nog een monopolie kunnen hebben voor wat betreft websites met ActiveX, maar in Chrome zit niks wat Firefox, Safari of Edge niet over kan nemen.

Ik denk dat je bedoelt “in veel landen een groot marktaandeel”, maar marktaandeel heeft niets met monopolies te maken.
Dan zit je verkeerd. Er zit net een hoop dingen in Chrome die andere browsers niet hebben.

Google doet de laatste jaren wat Microsoft ooit met IE deed: eigen standaarden erdoor duwen, concurrentie uit de markt duwen (de Opera-CEO kan je vertellen hoe ze gedwongen werden om op de Chrome-engine over te schakelen).
Dan zit je verkeerd. Er zit net een hoop dingen in Chrome die andere browsers niet hebben.
Zoals? Ik gebruik Firefox en mis niks uit Chrome.
de Opera-CEO kan je vertellen hoe ze gedwongen werden om op de Chrome-engine over te schakelen
Niemand werd gedwongen de chrome engine te gebruiken. Als kleine partij werd het te duur om een eigen engine te onderhouden, terwijl een engine voor gebruikers geen onderscheindende feature is, en kozen ze ervoor om dit niet meer te gaan doen en een bestaande te pakken, om zo te kunnen besparen op ontwikkelkosten. Naast Chromium was er volgens mij alleen Firefox als open multi-platform engine en hebben ze voor de eerste gekozen. Ze zullen er wel een reden voor hebben gehad om zich aan Google te willen binden, maar Firefox was ook een optie en ze hadden met hun eigen engine door kunnen gaan als ze echt hadden gewild, dus gedwongen? Nah. Zal wel weer iets met licenties te maken hebben (misschien moesten ze met de Firefox engine hun hele browser opensourcen ofzo).

Een grotere partij als MS had hetzelfde dilemma en hebben dezelfde keuze gemaakt. Ik denk dat een engine onderhouden toch best wat resources vergt en het met de groeiende set aan webstandaarden gewoon te lastig is geworden. Als je ergens met de vinger naar moet wijzen zal het HTML5 zijn.

Op OS gebied zie je hetzelfde. Niemand begint nog een eigen OS. Alle nieuwe producten hebben allemaal Linux als basis. Een compleet nieuw OS is qua complexiteit gewoon niet meer te doen. Ik voorspel dat we naast Windows, Mac OS en Linux nooit meer iets anders krijgen dat enigszins relevant kan worden op OS gebied, en dat het aandeel van de rest, die nu eigenlijk uitsluitend op servers worden gebruikt, alleen nog maar kleiner gaat worden. Die kunnen gewoon niet meer meekomen omdat een OS tegenwoordig te complex moet zijn om met iets nieuws te komen. Wordt er daarmee iemand gedwongen om Linux te kiezen? Niet door Linux zelf, hooguit door praktische overwegingen.
Sociale druk is ook een vorm van dwingen.

Als zelfs Microsoft de handdoek in de ring gooit, dat terwijl de huidige Edge de oudste browser is die het web kent en zelfs zijn roots heeft in de eerste grafische browser die het web ooit gekend heeft. Waar blijft de hoop dat Mozilla, de last of the mohicans, dat ook niet gaat doen? Firefox heeft nog een grote backing vanuit de Linux/FOSS wereld, maar die is ook al jaren krimpende. Als een organisatie als MS, die met hun ontwikkelings kunde en kracht met 2 vingers in de neus prima Trident hadden kunnen multiplatformen (hebben ze in het verleden ook voor OSX gedaan) zonder dat dit effect heeft op hun omzet of winst er al de moeite niet meer voor wilt nemen, hoeveel kans geef je Mozilla nog de komende 5 of 10 jaar?

Hoe kun je mee gaan met een eigen engine als het web gedomineerd wordt door Google? Wanneer Google in feite de webstandaarden in handen heeft en deze domineerd door hun macht op browser gebied door Chrome en aan de website kant door o.a. hun Search? Door geen gebruik te maken van hun engine, blijf je altijd achter de feiten aan lopen. Of waar Microsoft wel eens tegen aan liep, doordat Blink op een hele andere wijze werkt dan dat Trident of Quantum dat doen, dat je archaistische meuk moet gaan bouwen waardoor o.a. je performance in elkaar klapt. Want de standaard wordt dan geschreven naar voorbeeld van Google. Zie bv een groot deel van het gezeik omtremt Youtube en het feit dat deze website uitermate belabberd draait op IE/Edge en ook minder werkt op Firefox dan dat het op Chromium doet. Het is al jaren schering en inslag.

We stuiven keihard af op een ernstigere situatie dan IE6. En dat allemaal omdat we (tweakers, nerds, geeks etc) uit angst voor IE Google die macht gegeven hebben.
Het zijn niet de nerds die Google de macht hebben gegeven. Het zijn voornamelijk de normale gebruikers die zich door Google’s trucs in hebben laten pakken. Nerds zijn maar een klein deel van het web. Tante Truus die youtube wilde kijken en een melding kreeg “installeer dit, daar wordt youtube beter van”, en dat vervolgens blind doet, is een veel groter deel. Díe mensen moet je aanpakken om Google te stoppen.

Maar ik denk dat Mozilla het nog wel even uithoudt hoor. Ze hebben net hun engine een grote upgrade gegeven. En ik denk dat ze zich goed realiseren dat Firefox op een blink engine het einde van Firefox betekent.

Overigens was Edge geen trident. Ze hebben Edge juist gemaakt omdat trident niet meer mee kon komen en ze iets nieuws nodig hadden. Edge is nu gewoon een Chromium skin, maar trident gaat nog wel even door (voornamelijk om legacy te blijven ondersteunen).

En nog meer overigens, trident was allang al multiplatform. Rond 2000 draaide ik IE5 op Solaris. Het was wel een beetje een gedrocht maar het was stabieler dan Netscape, die constant crashde...
Ah, dus het was niet zo dat in de begin jaren van Chrome die browser bij iedereen geïnstalleerd werd want IE was zo zuig. Dat het iedereen aangeraden werd want MS is de duivel, wat ik nu soms nog af en toe van gebruikers te horen krijg waarom ze Chrome gebruiken. Zonder enige druk vanuit Google zelf, stond in no-time bij vrijwel iedereen Chrome op de desktop. Vaak verstopt onder het IE icoontje ook nog eens. Pas later werd Chrome bij elk stukje software meegeleverd en op elke Google site in je neus gedrukt.

Waarom zou Firefox het niet overleven? Opera doet nog steeds mee. Edge is nu over. Brave doet het ondanks de nog schuinere bedrijfsethiek dan die van Google ook veel te goed.

Edgehtml bestaat al sinds IE9, is gewoon Trident in een nieuw jasje. In oude IE9 builds op Windows 7 had je onder de developer tools dat er nog als optie tussen staan. Want "bleeding edge", waar uiteindelijk de naam Edge als browser ook uit gekomen is. Edge als browser heeft al die legacy meuk van IE11 gedropped en is op dat edgehtml stukje verder gaan bouwen als UWP app.

Ik gaf al aan dat IE in het verleden multiplatform was, de OSX versie is wat bekender dan de UNIX varient. Netscape was op Windows destijds ook een hork. MS heeft die browser strijd niet alleen gewonnen door hun invloed in de OS wereld, maar ook omdat ze gewoon een betere -gratis- browser neer gezet hebben.
en youtube vertragen voor firefox gebruikers was/is ook 1 van die dingen volgens mij
Tsja, wanneer houdt het op experimenteel te zijn?
Wanneer je het onder een representatieve groep getest hebt.

Dit was niet in een representatieve groep getest.
Bij het volgende versienummer.
Een experimentele functie wil niet zeggen dat de functie instabiel is. Zelf brengt Tweakers waarschijnlijk ook regelmatig een nieuw knopje uit, om te kijken of het gebruikt gaat worden, en zo niet het weer verwijderd.

Daarnaast is 100'en gebruikers die klagen op 300-400 miljoen actieve Chrome gebruikers, nou niet echt een groot instabiliteit probleem.
Daarnaast is 100'en gebruikers die klagen op 300-400 miljoen actieve Chrome gebruikers, nou niet echt een groot instabiliteit probleem.
Het gaat ook om mensen die grote bedrijven vertegenwoordigen met miljoenen afnemers...
Als je miljoenen afnemers hebt moet je maar zien dat je niet vendor-locked-in bent met iets zoals Chrome. :)
Het gaat hier helemaal niet om vendor lock-in. Dat bedrijven Chrome gebruiken wil niet zeggen dat ze er aan vast zitten. Toevallig is het nu Chrome dat een bug heeft in een specifieke situatie.
Ieder bedrijf is vendor locked in. Moet je dan van al je software 2 leveranciers nemen? Dat gaat toch niet.
Ja maar als je zo afhankelijk bent van een browser kan je toch ook eens bijvoorbeeld naar FireFox kijken ? Kan me niet inbeelden dat dit zo een probleem zou zijn. En zien dat alles op beide werkt. Als er dan toch 1ntje niet werkt, kan je overschakelen op de andere.
Het probleem zakelijk is dat als je iets aanbiedt je het ook moet ondersteunen. Dus je kunt prima Firefox aanbieden of nog tig andere browsers maar als de gebruiker de helpdesk met vragen belt moet je vervolgens wel met een oplossing komen. Dus hoe meer verschillende browsers je hebt hoe meer tijd en kennis je nodig hebt.

En er zijn er wel twee hoor we draaien nog IE 11 dus daar kan men altijd wel op terug vallen maar het wordt wel heel veel om ook nog Firefox te gaan ondersteunen. Je moet het allemaal ook beheren weer en updaten etc. het lijkt heel simpel maar er komt iets meer bij kijken.

Buiten dat is het natuurlijk ook een management beslissing.
Das een keuze uiteraard, maar ik zelf mag IE11, Edge, Firefox, Chrome en Safari ondersteunen. Dus ik kan zien dat het maar werkt. En soms moet je knopen doorhakken. Ik heb ook gewoon sommige functies die niet op Safari werken, maar in al de rest wel. Als jij perse een mac wilt gebruiken, jouw keuze, maar dan werk X bijvoorbeeld niet omdat Safari dit niet zal ondersteunen. Het is een andere mogeljikheid. Of je kan een workaround verzinnen zoals bijvoorbeeld de full screen
het gaat erom dat Google hier Van buitenaf een probleem heeft gecreëerd en de Admins het maar mochten uitzoeken.

Heeft google niet zoiets als een Stable version die een half jaar achterloopt mbt nieuwe feat.
Deze bug treft bijna enkel multi user opstellingen zoals terminal servers.
Ik verwacht niet dat in deze situaties vaak gebruik wordt gemaakt van beta software.

Misschien zouden ze voor dit soort experimentele functies de uitrol wat geleidelijker kunnen doen.
Deze bug treft bijna enkel multi user opstellingen zoals terminal servers.
Ik verwacht niet dat in deze situaties vaak gebruik wordt gemaakt van beta software.
In dat soort omgevingen rol je dan ook niet zomaar updates uit zonder ze te testen, ongeacht of dat de leverancier ze als 'stable' aanmerkt.
In dat soort omgevingen rol je dan ook niet zomaar updates uit zonder ze te testen, ongeacht of dat de leverancier ze als 'stable' aanmerkt.
Dat gebeurt in dit soort omgevingen ook niet en dat was in dit geval ook niet nodig. De feature is "aangezet" zonder duidelijke communicatie zonder dat je daarvoor een nieuwe versie chrome hoeft te installeren.
Wat al niet zou mogen, in dit soort omgevingen updates van chrome of wat dan ook altijd eerst nog getest, dit ging om een nieuwe functie. Geen kritische bug, enterprises willen graag controle over wat er gepushed wordt, wat google gewoon deed is gewoon fout.
De feature is "aangezet" zonder duidelijke communicatie zonder dat je daarvoor een nieuwe versie chrome hoeft te installeren.
Google kan remote settings aanpassen aan Chrome ? Wow.

Nog meer redenen om ver van Chrome weg te blijven.
Er is geen sprake van iets uitrollen, want deze setting kwam niet mee met een nieuwe versie, en er was dus geen sprake van een installatie.

Want in reeds geinstalleerde installaties werd deze setting ook van de ene op de andere dag spontaan enabled. Google heeft blijkbaar die mogelijkheid om dat zomaar te doen.
Ja, dat zal het zijn.
Uitrollen ja sure. Uitrollen zonder tussenkomst van gebruikers/beheerders? Nee.

Neem het in een update mee, dan kun je zelf kiezen om te updaten. Automatische updates staan hier met een reden uit. Blijkbaar gooien ze dus wel expirmentele features aan en uit..
Niet als je je zakelijke product niet in een zakelijke omgeving getest hebt.
Maar is het ook 5 maanden in beta geweest bij zakelijke gebruikers?
Die hanteren vaak toch net wat strengere policies en sowieso een heel andere omgeving.
Hier een jaar geleden ook ineens problemen gehad met firefox omdat het verkeer via een proxy loopt, dus bij bijna elke pagina met login (t.net, google, etc) kreeg ik een niet te negeren waarschuwing dat ik vatbaar was voor een man-in-the-middle aanval. Blijkt een vinkje niet aan te staan om domein-settings over te nemen :/
Dat is niet iets wat Google kan doen, dat is juist iets wat bedrijven moeten doen.

In theorie moet gewoon elk bedrijf wat chrome gebruikt een paar mensen omzetten naar de test-versie zodat die het kunnen uittesten en commentaar geven.
Hetzelfde geldt voor windows.

Als er iets ge-update moet worden dan is het altijd aan de klant om dit te testen of het voor hem ook werkt, en tja in deze tijd met gepushte updates betekent dat simpelweg dat je deels proefpersonen moet aanleveren anders krijg je de update gewoon door je maag gesplitst...
In theorie moet gewoon elk bedrijf wat chrome gebruikt een paar mensen omzetten naar de test-versie zodat die het kunnen uittesten en commentaar geven.
Yeah... Right... Dit issue speelt kennelijk alleen bij een multiuser environment, zoals bv. terminal servers. Daar kan je het niet uitrollen voor een 'paar' users, dat is alles of niets op een server. Als je het dus test op een niet terminal server lijkt er niets aan de hand te zijn... Daar komt nog eens bij dat veel organisaties direct alle terminal servers updaten met dezelfde updates om geen rare issues te krijgen bij gebruikers die wisselen van sessie/server.

En een beta versie van Chrome testen in een (live) terminal server omgeving gaat geen enkele beheerder doen.
Binnen citrix kun je gewoon test servers aanmaken, en langzaam gebruikers verhuizen naar de "nieuwere" server. Als je klachten krijgt kun je altijd nog even dit proces pauzeren en uitvogelen wat er aan de hand is.

Zomaar even iets updaten in een live omgeving is nergens een goed idee.
Behalve dat het hier alsnog niet om updaten gaat... zónder update zijn hier op afstand settings aangepast.
Definitie van een update: Iets verbeteren of aanpassen.

Maakt niet uit hoe het gebeurd, op afstand iets aanpassen (een of andere feature aanzetten), kun je gewoon zien als update. Google had dit A) moeten communiceren B) het aan beheerders overlaten.
Een daadwerkelijke update gaat gepaard met een change in versienummer; dit is niet gebeurt.
Dit is een instelling van buitenaf, zonder toestemming (en in het geval dat auto-update uit stond expliciete ontzegging) is gewijzigd.
Mensen die er zwaar aan willen tillen kunnen dit (m.i.) gewoon tellen als buiten toegekende rechten en restricties willen stappen; en dat is een verdomd goeie reden om software preventief niet langer te gebruiken; iets dat óók google moet willen voorkomen :)

Stel dat die call-to-home functionaliteit veel meer "mag"(/kan) dan preferences wijzigen en je hebt het hier (voor enterprise) over zelfs een mogelijk attack-surface dat uitgesloten kan moeten worden (al is dat wss wat overtrokken; niets sluit voor nu uit wat middels die call to home NIET kan omdat het ongedocumenteerd is.)
Kan prima hoor. Gewoon een X aantal test servers hebben.

Zet nieuwe chrome op de test servers, zet een 10 tal gebruikers op de test servers en gaan.

Daarnaast, dit kwam niet met een update mee. Maar gewoon een configuratie change van de kant van Google zonder tussenkomst van gebruikers/beheerders.

[Reactie gewijzigd door garriej op 15 november 2019 12:35]

Daarnaast, dit kwam niet met een update mee. Maar gewoon een configuratie change van de kant van Google zonder tussenkomst van gebruikers/beheerders.
Dat is wat NIJ het meest zorgen baart.
Straks zetten ze er een rogue CA in en tappen al je verkeer af.
Je wil toch water wat je in huis haalt en hoe het werkt.
Dan vraag ik me ook af wat's next? De volgende 'handige' feature is een remote shell/busybox activeren...
Ik vind dit ook compleet van de pit gerukt. Maar zeuren over Chinezen en hun Spyware , fit is duizendmaal erger.
Nooit de keuze voor Chrome begrepen. Firefox is de enige browser die nog te vertrouwen valt.
[...]
Yeah... Right... Dit issue speelt kennelijk alleen bij een multiuser environment, zoals bv. terminal servers. Daar kan je het niet uitrollen voor een 'paar' users
In een beetje professionele omgeving kan je het wel gewoon uitrollen voor een paar users hoor.
Daar komt nog eens bij dat veel organisaties direct alle terminal servers updaten met dezelfde updates om geen rare issues te krijgen bij gebruikers die wisselen van sessie/server.

En een beta versie van Chrome testen in een (live) terminal server omgeving gaat geen enkele beheerder doen.
Kijk, als dit jouw/jullie beleid is dan is dat wmb best, alleen ga dan niet lopen janken als de boel stuk is omdat je er gewoon maar wat updates ongetest overheen gooit en hoopt dat je omgeving in stand blijft.

Een beetje professionele omgeving kan dit gewoon testen en hoort dit gewoon te testen voor elke update / patch.

Blind updaten is leuk als je 10 users op je terminal server(s) hebt zitten. Heb je er 3000 dan loop je groot risico ontslagen te worden als je ongetest spul toestaat
Ik zeg niet dat ik het niet kan en dat ik er last van heb gehad, maar er zijn best veel grote organisaties die hun productie servers in 1x updaten en eigenlijk geen andere keuze hebben ivm. hoe het is ingericht en/of de tools die worden gebruikt. Nu kan je zeggen "Verkeerde keuzes in het verleden!" en wellicht heb je daar gelijk in, maar dit is de realiteit in het IT landschap. Niet elke ITer heeft de luxe om bij een groot bedrijf te zitten waarbij het IT budget groter is dan de totale omzet van de meeste andere bedrijven.

Er zit een hele berg klanten ergens tussen die 10 en 3000 gebruikers, welke geen capaciteit/geld hebben voor OTAP. Dit is het gros van MKB Nederland. En zelfs bij Enterprise omgevingen gebeurd dat niet altijd even netjes.
Er zit een hele berg klanten ergens tussen die 10 en 3000 gebruikers, welke geen capaciteit/geld hebben voor OTAP.
Capaciteit is gewoon in te huren en geld, tja dat is puur een keuze. Als ze 1x een update krijgen die fout genoeg is dan is er daarna wel geld voor beschikbaar als ze nog bestaan...

En als je zelf geen geld over hebt voor je eigen IT-security, tja dan is je gejank feitelijk alleen maar dat Google niet genoeg geld investeert in jouw IT-security.
Dit gaat echter niet om updaten; het gaat om het modificeren van settings vanuit google, zónder update/versionchange/patchnotes; hoe zou een beheerder dát moeten detecteren/vermoeden/voorkomen? onmogelijk.
Google had zodoende vooraf moeten kunnen beredeneren hoe not-done zo'n actie is met een userbase als Chrome/Chromium.
Google heeft iets gepushed, je werd zelfs niet op de hoogte gebracht van een wijziging, hoe wil je dit dan testen
Yeah... Right... Dit issue speelt kennelijk alleen bij een multiuser environment, zoals bv. terminal servers. Daar kan je het niet uitrollen voor een 'paar' users, dat is alles of niets op een server.
In zo'n situatie ga ik er van uit dat je minimaal 3 vrijwel identieke omgevingen: een test omgeving, een acceptatie omgeving, en een productie omgeving.
Jij werkt zeker in een Enterprise omgeving die daar budget en capaciteit voor apart zet... Het gros van de IT omgevingen werkt daar echt niet mee!

Em wat @garriej aangeeft, dit kwam niet met een update mee... *facepalm*
Hebben we, waren allemaal opeens kapot. :'(
In zo'n situatie ga ik er van uit dat je minimaal 3 vrijwel identieke omgevingen: een test omgeving, een acceptatie omgeving, en een productie omgeving.
Dat had in dit geval helemaal niets uitgemaakt omdat je zelf geen update hoefde te installeren voor de bug actief werd. Ook al heb je een volledige OTAP straat; remote geactiveerde functies blijven een risico.
Ook al heb je een volledige OTAP straat; remote geactiveerde functies blijven een risico.
Daarom sta je dat soort applicaties ook niet toe.
Ik snap daadwerkelijk niet waarom je op een shared desktop server automatische updates van chrome aanzet als je main bedrijfsproces afhankelijk is van de werking van chrome.
Dan zet je die auto-updates toch uit?
Het gaat helemaal niet om een update, en dus ook niet om de auto-update functionaliteit.

Die had ik namelijk gewoon netjes uitstaan (doe ik altijd), en toch was ook bij mij de setting gewoon aangepast door Google.

Blijkbaar zit er een soort 'call home'-functionaliteit in Chrome die contact maakt met Google en settings synchroniseert.
Dit is toch voor Microsoft de ideale kans om haar nieuwe Edge-Chromium te promoten?

Sowieso snap ik die dat complete callcenters plat liggen als het probleem zich niet in andere browsers voordoet. Dan gebruiken ze toch even de browser van het OS?

Gezien de impact verwacht ik een aantal dikke schadeclaims richting Google en David Bienvenu.

[Reactie gewijzigd door RoestVrijStaal op 15 november 2019 14:12]

Sowieso snap ik die dat complete callcenters plat liggen als het probleem zich niet in andere browsers voordoet. Dan gebruiken ze toch even de browser van het OS?
Moet die wel beschikbaar zijn voor gebruikers. Vaak zie je dat bijvoorbeeld IE wordt geblokkeerd, als het niet nodig is, en dat men een company policy heeft om één specifieke browser te hebben ipv meerdere.

Tevens is er software die alleen in specifieke browsers werkt, en niet in andere browsers (en nee, dit is niet alleen bij IE-gebaseerde apps).
[...]


Moet die wel beschikbaar zijn voor gebruikers. Vaak zie je dat bijvoorbeeld IE wordt geblokkeerd, als het niet nodig is, en dat men een company policy heeft om één specifieke browser te hebben ipv meerdere.
Dan zou het zelfs gemakkelijker moeten zijn om het tijdelijk te activeren. Als mensen hun werk niet kunnen doen omdat opeens met gereedschap X het werk niet meer geklaard kan worden, zou ik tijdelijk toestaan dat mensen met ongebruikelijk gereedschap Y het werk doen. It sucks, but it does the job.
Tevens is er software die alleen in specifieke browsers werkt, en niet in andere browsers (en nee, dit is niet alleen bij IE-gebaseerde apps).
Met de verchromiuming van het browserlandschap en het feit dat een aantal nieuwe W3C Drafts uitsluitend geschreven zijn door Google medewerkers (zoals WebUSB) was dat al ruim aan zitten te komen.

[Reactie gewijzigd door RoestVrijStaal op 15 november 2019 14:26]

Dit is geen kans om de nieuwe Edge te promoten, want die had er ook last van volgens de meldingen die ik heb gelezen. Elke Chromium derivaat die versie 77 of nieuwer gebruikt was getroffen.
Egde Chromium had precies hetzelfde op hetzelfde moment.. Dus Google push dit ook gewoon naar andere Chromium browsers.
Wij hadden geen last van dit probleem, maar Edge is niet beschikbaar op Windows Server 2016. Sterker nog, Microsoft adviseert zelf om Internet Explorer 11 te gebruiken. :')
https://docs.microsoft.co...ploy/about-microsoft-edge
Wat raar dat de software zich blijkbaar anders gedraagt in een Citrix/RDS omgeving. Dat lijkt me meer een bug in Citrix/RDS dan in de software. Je hoeft als software toch niet te weten in wat voor omgeving je draait?
Het hangt er vanaf hoe je zaken afhandelt en afvangt. Binnen een RDS/Citrix omgeving zijn er doorgaans meerdere mensen aan het werk. Als je enkel reageert op elk lock event wat het OS registreert ipv te kijken per user sessie dan gaat het al snel mis.
Zal ik 't nog mooier maken. Mijn collega zat op het console via Vsphere ingelogd en dan liep chrome gewoon door.

Logt hij vervolgens via RDP in met hetzelfde account, op dezelfde server. Dan werd chrome wel wit.
Hangt ervanaf hoe je je software schrijft...

Normaliter hoef je geen rekening te houden met in wat voor omgeving je draait, maar als je dingen als lock-screens wilt detecteren buiten de standaard api's van MS om, tja dan kom je in grijze gebieden waar een normale omgeving maar 1 lockscreen kan hebben, terwijl een terminal /citrix server meerdere lock-screens kan hebben.

Windows biedt waarschijnlijk geen higher-level api aan om te detecteren of het lock-screen actief is (of die is te traag bijv) en als je dan naar lower-level api's gaat dan is het op eigen risico...
Nee hoor. Uit de stukken van Google zelf blijkt dat ze helemaal geen rekening hebben gehouden met gelijktijdige gebruikers. Ze bekijken álle PID's op een machine, en als één daarvan op slot gaat bevriest ieder open tabblad op die machine. Dat is geen bug, maar gewoon een heel verkeerde en stomme manier om je feature vorm te geven.
Als je het 5 maanden test in beta en vervolgens het uitrolt naar stable en dan deze problemen naar boven komen is de vraag in hoeverre je beta test betrouwbaar zijn.
Het issue zit hem er hier meer in dat de bug vooral optreed in Terminal server / Citrix omgevingen. Dat zijn omgevingen waar doorgaans niet met Beta software wordt gebruikt en zeker niet als het om een browser gaat.

Een test bij consumenten is niet altijd representatief voor de gehele userbase.
Maar wel omgevingen die je zou moeten meenemen in je test fase als je je product ook voor zakelijke omgevingen uitbrengt.
Het zou minstens schelen als changes als-deze gecommuniceerd worden en enkel met een versionchange gepaard gaan; dan hoeft men het allereerst al niet te "ruiken" dat het vanuit die hoek komt; dat lijkt mij ook het meest storende aan dit specifieke voorval.
We hebben er zelf ook last van en het is dankzij Tweakers dat we weten waarom dit gebeurd. Beetje zonder updates settings aanpassen is echt not-done in zakelijke omgevingen.

Google laat hier mee goed zien waarom we IE/Edge en Firefox aanraden als browsers om te gebruiken.
Dat snap ik, wss is de "benodigheid" van Chrome vermoedelijk ook eerder een wens vanuit gebruikers, niet? Of is dat eerder vanuit flexibiliteit geweest? Zelf heb ik iig wel het idee dat de gemiddelde medewerker iets bekender is met Chrome dan FF en indien die tussen die twee kan kiezen ook vanzelfsprekend voor Chrome gaat; maar misschien zie ik dat wel fout/gaat dat elders wel heel anders :)
We hebben alle 3 de browsers omdat afhankelijk van wanneer een web app ontwikkeld is, het soms alleen in 1 browser werkt. Sommige zaken alleen IE, andere Firefox en ook een aantal alleen in Chrome.

Plus een beetje persoonlijke voorkeur. Binnen onze organisatie is IE veruit de meest gebruikte browser, dan Firefox en ver daar achter pas Chrome.

Als we de mogelijkheid hadden, hadden we liever 1 browser. Meerdere browsers veroorzaakt meerdere kopzorgen. Onze insteek is wel "Werkt het in 1 browser, problem solved".
Ah leuk om te weten dat IE en FF meer voorkomen als ik gebaseerd op enkel gevoel had verwacht :)
En de insteek voor 1 browser klinkt wel zo logisch; je bent dan vast ook niet al te snel extra tijd aan het spenderen om hetzelfde wiel 3 maal uit te vinden / zelfde probleem tot 3 maal op te lossen :) lijkt mij iig een win-win daarin!

[Reactie gewijzigd door Annihlator op 15 november 2019 15:47]

De meeste mensen maakt het ook vandaag de dag echt geen bal uit welke browser ze gebruiken. We raden vanuit de IT voornamelijk gewoon IE en FF aan. Maar mensen moeten het helemaal zelf weten waar ze welke browser voor gebruiken. En de problemen vallen an sich mee, want als iets in 1 browser werkt, doen we niet snel moeite om het in andere browsers te laten werken. Tenzij het apps zijn die door onszelf ontwikkeld zijn/worden, die werken in alle 3(4, safari ook) de browsers.

En dit met Chrome kan nog wel eens een staartje gaan krijgen.
Als je browser zowel door consument als zakelijke klanten wordt gebruikt lijkt mij dat je Terminal Server / Citrix omgevingen juist mee neemt in je beta test's. En als je als Google zijnde dit niet in de gaten hebt dat moeten ze daar toch wat meer verbinding met hun klanten/userbase gaan leggen.
Het issue zit hem er hier meer in dat er niet getest wordt op Terminal Server/Citrix omgevingen.
Zal niet of nauwelijks getest zijn op RDS/Citrix omgevingen denk ik. Dus dan komt het niet naar voren.
Waarom bestaat er niet gewoon een 'rollback' knop in Chrome (en software in het algemeen), waarin je kunt kiezen welke voorgaande versie je wilt?
Het ging hier helemaal niet om een nieuwe installatie, dus een rollback naar een eerdere versie (77 in dit geval) zou niets oplossen.

Het ging hier om een bestaande installatie, waarin van de ene op de andere dag opeens deze setting door Google was enabled.

Ik vind het raar dat Google zomaar dit soort settings kan enablen in een bestaande installatie. In een nieuwe versie kan ik me nog indenken (nieuwe functionaliteit), maar dat ze ook bestaande installaties zomaar kunnen beinvloeden vind ik op zijn minst opvallend te noemen.
De aanpak van Google is heel gebruikelijk bij het introduceren van nieuwe features. In plaats van de nieuwe feature voor alle gebruikers tegelijk in te schakelen met een update, hebben ze ervoor gekozen om deze geleidelijk aan te zetten. Helaas hebben ze deze keer niet op tijd de gevolgen van deze nieuwe feature voor bepaalde gebruikersgroepen gezien.
Google Chrome heeft ook een Software Reporter Tool die scant voor software die mogelijk problemen veroorzaakt met browsen. Blijkbaar kan deze tool ook software verwijderen, zie https://www.ghacks.net/20...ftware_reporter_tool-exe/

Enige tijd geleden had de laptop (oud model laptop met Windows 10) van mijn ouders een probleem, hoge CPU load, wat dus door deze software veroorzaakt werd.
De activering van deze experimentele feature leek niet op een versie gebaseerd te zijn.

Zelfs rollbacken zou een flinke klus zijn omdat de feature al maanden erin zat (hetzij gedeactiveerd) maar door het gebruik van de huidige config wordt het natuurlijk geactiveerd.
Wat een verschrikkelijke schijtbug was dit zeg. Bij ons bedrijf zijn we gisteren maar weer Internet Explorer gaan gebruiken voor een dag want er was geen land mee te bezeilen met Chrome.
Misschien tijd om over te gaan op Edge met Chromium
zelfde issue was daarmee.
Ik denk wel dat Microsoft dit gaat meenemen in toekomstige ontwikkelingen van de nieuwe Edge en niet zo maar blind changes in Chromium mee gaat nemen.

[Reactie gewijzigd door batjes op 15 november 2019 16:21]

Leuk, maar die had er dus ook last van. Fijn he, allemaal dezelfde engine en centraal punt waar ze instellingen vandaan halen. IE all over again. ;(
Zodra die beschikbaar komt op 15 januari is dat het eerste wat wij gaan doen
De oorzaak is te herleiden tot een experimentele functie die het Chrome-team naar de stabiele versie bracht om meer feedback te verkrijgen.
Dus ze hebben de stabiele versie expres instabiel gemaakt om te kijken wat er gebeurde? Handig.
experimentele functie is niet per se alpha/beta-code. de functie is experimenteel, niet de code. maw; kan weer verwijderd worden als blijkt dat de functie niet nuttig/gewenst/populair blijkt.
Ja maar je zou hopen dat je in een "stabiele" versie niet hoeft te dealen met iets dat experimenteel is. Dat het meteen weer kan worden verwijderd is niet zo boeiend. Stabiel moet stabiel blijven.
nouja wat ik bedoelde te zeggen is dat experimentele functies stabiel kunnen zijn.

Op dit item kan niet meer gereageerd worden.


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True