Google publiceert fix voor dataverlies Chrome's WebView op Android

Google heeft een bijgewerkte versie van Chrome 79 voor Android uitgebracht. De versie repareert de bug in WebView, die problemen met dataverlies veroorzaakte voor apps die gebruikmaakten van het renderingonderdeel.

Google stelt in de release notes van Chrome 79.0.3945.93 voor Android gerust dat de app-data niet verwijderd was, alleen simpelweg niet zichtbaar was in externe apps die van WebView gebruikmaken. Met de update wordt de data opnieuw zichtbaar.

Google zag zich eerder deze week genoodzaakt de update naar versie 79 van Chrome op Android te pauzeren nadat bleek dat apps die gebruikmaken van de WebView-extensie geen data meer toonden. Het probleem bleek te schuilen in het niet migreren van localstorage, WebSQ en journalbestanden voor cookies en QuotaManager. Google-ontwikkelaars wezen ontwikkelaars op het bestaan van bètaversies, waardoor de bug aan het licht had kunnen komen.

Andere wijzigingen van Chrome 79.0.3945.93 op Android zijn dat de browser voortaan waarschuwt als een ingevoerd wachtwoord eerder uitgelekt is geweest. Ook is er ondersteuning voor de WebXR Device-api voor vr op het web en kunnen favorieten voortaan van plek in de lijst verwisseld worden.

Reacties (18)

[kwakzalver]

Google-ontwikkelaars wezen ontwikkelaars op het bestaan van bètaversies, waardoor de bug aan het licht had kunnen komen.

Het is wel frappant dat Google de schuld afschuift op ontwikkelaars dat zij de verantwoordelijkheid hebben de bétaversies te testen.
Was netter geweest als ze het gewoon gefixed hadden en wellicht hadden de apps met de bétaversies ook gewoon gewerkt. Het kern van de probleem zat hem in de migratietool. En die test je nu net niet als ontwikkelaar.

Het leest nu als: 'we ontwikkelen wat en gooien het over de balk' en als het niet werkt is het niet onze schuld.

[GertMenkel]

Mwah, ik kan me de frustratie van de Google-medewerkers ook wel voorstellen. Er zijn zo'n 2.5 miljard Android devices in omloop en niemand heeft de afgelopen weken een probleem gemeld met de beta. Nog steeds is het een slordig foutje van Google, maar zoiets kan nou eenmaal gebeuren als je zoveel verschillende softwareproducten maakt.

Overigens is het sowieso verstandig als ontwikkelaar de bèta versie te draaien want Chrome verandert best wel vaak features en implementaties. Als je de dev versie draait, kun je als ontwikkelaar enkele weken vantevoren alvast je applicatie fixen voordat de wijziging daadwerkelijk naar je klanten wordt uitgerold. Dat is niet per se om Google's bugs voor ze te vinden, maar om jezelf als ontwikkelaar in te dekken tegen risico's van het veranderende web. Het vinden van bugs als deze is dan een mooie bijkomstigheid voor Google.

[WhiteDog]

Ik stuur regelmatig bug requests in en bevestig bugs die anderen melden in Google producten, waaronder Chrome. Ik doe dit al jaren. Weet je hoeveel keer ik al feedback heb gekregen van een Google-medewerker? Nul keer. Integendeel, soms werden mijn berichten gewoon verwijderd.

De frustratie bij de ontwikkelaars is eerder dat de juiste bug reports niet tot bij hun geraken.

[Luchtbakker]

Ik stuur regelmatig bug requests in en bevestig bugs die anderen melden in Google producten, waaronder Chrome. Ik doe dit al jaren. Weet je hoeveel keer ik al feedback heb gekregen van een Google-medewerker? Nul keer. Integendeel, soms werden mijn berichten gewoon verwijderd.

De frustratie bij de ontwikkelaars is eerder dat de juiste bug reports niet tot bij hun geraken.

Aan de ene kant heel frustrerend, want je verwacht een soort bedankje van Google. Maar bedenk dat er geen honderden mensen aan 1 dienst zitten te werken die de tijd hebben om elke bug request zodanig te bekijken en te behandelen dat ze je persoonlijk kunnen bedanken voor de energie dat je er in hebt gestoken.

Dat is het nadeel aan grote bedrijven.

[Verwijderd]

Het zit 'm niet zozeer in de schouderklopjes en bedankjes. Het zit 'm erin dat je in ieder het gevoel hebt dat jouw input waardevol is en dat er wat mee gedaan wordt. Dan kan makkelijk door jouw feedback een casenummer te geven en die terug te laten komen in de lijst met updates in een nieuwe versie. Ook als er een onduidelijkheid is van de ontwikkelaar moet de ontwikkelaar in de gelegenheid zijn om contact met je te zoeken. Veel bedrijven stoppen de bouwers het liefst in kerkers, ver van de buitenwereld af. Een ontwikkelaar storen is immers onderbreking werkproces... Functioneel beheerders hadden deze taak tijden, maar deze worden ook aan de ketting gelegd en mogen hooguit een mailtje beantwoorden. Zodra dit weer (gekaderd) los wordt gelaten dan is het een winwin-situatie.

[Zenomyscus]

Frustratie zou kunnen. Maar dat maakt het nog niet de verantwoordelijkheid van de gebruiker. Ik heb niet de behoefte om te ontwikkelen in brakke software en steeds af te vragen of het aan mij of aan de software ligt.. Zeker niet als ik daar niet voor betaald krijg.

Als je de dev versie draait, kun je als ontwikkelaar enkele weken vantevoren alvast je applicatie fixen voordat de wijziging daadwerkelijk naar je klanten wordt uitgerold.

Daarom zijn er standaarden. Je moet er vanuit kunnen gaan dat uitgerolde producten het wekelijks veranderen.

[GertMenkel]

Standaarden zijn leuk maar die worden toch bepaald door Google en Mozilla. Google heeft bijvoorbeeld (thank god) autoplay via javascript pas mogelijk gemaakt na interactie door de gebruiker waardoor een heleboel websites die de oude API gebruikten kapot gingen. De standaard gaf aan dat browsers een beperking konden stellen op wanneer audio kom worden gespeeld en dat het zou kunnen dat playback het in bepaalde gevallen niet deed, maar omdat niemand beperkingen stelde had geen enkele programmeur hier rekening mee gehouden.

Toen ging webaudio over de kop, gingen allerlei sites en games kapot en waren een heleboel mensen te laat met het op tijd werkend maken van de nieuwe API.

Dit soort dingen kunnen nu eenmaal gebeuren op het web. Kijk bijvoorbeeld maar naar de welkome ontwikkeling dat Mozilla nu standaard trackers blokkeert. Google heeft ook plannen voor ad blocking. Als je als ontwikkelaar kiest je kop in het zand te steken en alleen met huidige versies van browsers test, krijg je geheid dit soort problemen tegen je kop geslingerd.

Gewoon zeggen "er is een standaard dus ik hoef niet steeds te testen" zou werken als je API neutraal was. Als Windows developer kun je ervan uitgaan dat dingen blijven werken op nieuwe Windows-versies tenzij er een grote overhaul komt (denk: Vista), als web developer komen die overhauls een stuk sneller met de snelle ontwikkeling van het web. Als je dat niet wilt, kies je een stabielere API (native applicaties bijvoorbeeld).

Je hoeft ook niet de Chrome Canary als daily driver te gebruiken, maar je zou hem wel in je testing pipeline moeten stoppen, en eens in de zoveel tijd handmatig eens een keer kijken. Nog steeds zullen er wijzigingen en bugs in browsers zijn, maar jij zult er geen problemen van ondervinden in productie zoals de mensen die in het originele bug report moord en brand schreeuwden.

[Aaargh!]

Tja, ik vind het erg vreemd dat Google zomaar een dependency van een bestaande app update. Dat je dat als onderdeel van een OS update doet is 1 ding, maar er worden nu zo veel onderdelen van Android op random tijdstippen door Google geüpdate, daar valt haast niet tegenaan te testen.

Eigenlijk betekent dit dat je Android app op elk willekeurig moment stuk kan gaan (en je gebruikers komen bij jou klagen). Ik blijf het liefst zo ver mogelijk weg van het gebruiken van welke library van Google dan ook als die via de Play store updates krijgt.

[GertMenkel]

De dependency is een bekende op het moment dat je op de stiekem-een-webapp platformen als Cordova ontwikkelt. Het is maar goed ook dat Google deze updatet, anders zouden we zoals in de oude Android-dagen nog steeds moderne telefoons op Chrome 60 hebben draaien.

Dit is makkelijk te voorkomen door niet op een API te bouwen die ieder moment kan worden bijgewerkt (dus eigenlijk alles dat niet web development is). Mijn website kan ook kapot gaan doordat mijn klanten Chrome updaten, dat is nou eenmaal hoe web development tegenwoordig werkt.

[mocean]

Het was een bug niet in de browser, maar in de webview, waarvan het testen van beta's geen makkelijke taak is.

Plus de fout zat in een change waarvan de impact totaal onderschat is. 'Even' een profiel-dir moven en een paar directory's vergeten, echt een knal van een fout. Dit had bij de eigen QA of design van de change wel eerder mogen blijken.

[GertMenkel]

Testen met een nieuwe webview is makkelijk hoor. Je downloadt de Android System WebView Dev/Beta/Canary en schakelt deze in in de instellingen op je telefoon. Ik heb zojuist in 30 seconden mijn Android WebView naar Chrome 81 gezet.

De change lijkt enkele keren door review heen te zijn gegaan, ik snap niet helemaal hoe dit precies verkeerd uitkwam. Van wat ik gezien heb, zijn profielmigraties hier niet goed getest vanwege een details over hoe de test is opgezet. Het issue dat de wijziging moest oplossen en de commits gingen alleen over de cache, niet de localStorage-data, dus dat er niet expliciet naar localStorage-data is gekeken bij deze test kan ik begrijpen.

Hopelijk schrijft Google nu meer regressietests maar dat zullen we in de toekomst maar moeten zien.

[mocean]

Ik zou als developer/architect een andere oplossing gaan bedenken zoals een andere DB optie zoals Cordova SQLite.

[SunnieNL]

Ja, dat was wat ik ook las...
Ze doen toch zelf ook QA? Dan hadden ze dit probleem toch ook op moeten pikken?
Het helemaal afwentelen naar beta versies, dus je had het kunnen weten, is niet heel erg netjes naar je "klanten" toe.

[TWyk]

Beta testers zijn met name bedoeld voor testen impact en kwaliteit van nieuwe features.
Niet voor een regressietest op bestaande functionaliteit.
Daar moet je als software ontwikkelaar zelf voor zorgen.

[Verwijderd]

Kuch... met al die Agile methodiek zijn veel ontwikkelaars letterlijk de weg kwijt in de software. Alles moet tegenwoordig snel gebeuren met net genoeg aan logging om vooruit te komen. Als je helemaal geluk hebt is een bouwer van bedrijf gewisseld en mag de nieuwe ontwikkelaar met ehm… de rotzooi van een ander beginnen. Ik ben ooit eens op sollicitatiegesprek bij een ontwikkelbedrijf gekomen om te kijken wat er nu precies mis was met hun software. Zodra ik het woordje regressietest noemde was het gesprek zo goed als over

[Anonymoussaurus]

Omdat ik hier niet mag linken naar APKMirror (terwijl dat gewoon een zeer legitieme site is, omdat de APK's gescand en geverifieerd worden door AndroidPolice): hij staat op APKMirror (tweede pagina).

[t_weak]

Nu ook die versie via Appstore, wel erg goeie opmerking van je!

[Anonymoussaurus]

Dankje. Raar dat 'ie dan zoveel minnetjes krijgt .