"Push notificaties zijn voor deze browser geactiveerd"

[WCA]

Ik krijg elke keer dat ik tweakers een tijdje (paar uurtjes, of een nacht) niet geopend heb, en daarna weer open. de volgende push notificatie:


Hoort dat zo? In het verleden was dit niet het geval. 't is op zich niet zo erg, maar het lijkt me niet dat dit zo bedoeld is.

Ik draai Firefox 64.0.2, en dit probleem doet zich nu een paar weken (maanden?) voor. Naast een (op tweakers) uitgeschakelde adblocker, draai ik geen plugins die content beinvloeden. Wel heb ik de alles wat standaard aan staat in firefox met betrekking tot tracking protection etc gewoon op aan staan (de default opties)

Mocht dit expected behaviour zijn, dan hoor ik dat natuurlijk ook graag

[jochem4207]

Ik denk dat dit komt als tweakers iets update aan de backend/db. Krijg ze veel te vaak, bloedirritant maar waarschijnlijk onvoorkomelijk

[ACM]

Wij bewaren in onze database dat jij van ons die notificaties zou willen. En in iedere browser waar je ons daarna mee bezoekt testen we of er al een 'subscription' is. Zonee, dan vragen we die aan je browser. Dan krijgen we een record met drie velden om de berichten naartoe te kunnen sturen.

Als we een nieuwe 'subscription' krijgen sturen we een bevestiging dat je ook in die - voor ons nieuwe - browser de notificaties krijgt.
Die bevestiging is natuurlijk voor de specificatie zelf niet nodig, maar hebben we destijds geïntroduceerd als een servicebericht. Je browser vraagt je tenslotte wel om toestemming, maar je krijgt daarna niet een duidelijke bevestiging dat het ook echt werkt.

Wat ook is gebleken met deze techniek dat die 'subscriptions' maar een beperkte houdbaarheid hebben; vziw is dat op zich geen onderdeel van de specificatie, dus men mag zelf kiezen hoe lang ze de subscriptions actief houden. Uiteraard vermeldt de specificatie wel dat je rekening moet houden met het feit dat subscriptions hebt niet meer geldig kunnen zijn.

Doordat er een nogal sterke ontkoppeling zit tussen wat de browser met jou communiceert en wat ie met ons (via javascript) communiceert, kunnen we niet zien of wij al eerder toestemming hebben gevraagd en simpelweg de subscription was verlopen of dat jij daadwerkelijk 'nieuw' bent met deze browser.

Er zijn wel workarounds mogelijk (bijvoorbeeld een cookie zetten), maar we hadden door onze eigen ervaring met deze feature (ik krijg hooguit elke paar maanden die melding) niet de indruk dat dat nodig zou zijn. En dan nog, als je die cookies weer zou verwijderen krijg je het natuurlijk ook steeds opnieuw

Maar het lijkt er dus op dat bij jullie browsers de levensduur van die subscriptions extreem kort is. Of dat er ergens een bug zit in dit traject bij ons of in de browser.

Ik heb geen idee wat de tracking protection er bijvoorbeeld mee doet.

[WCA]

Geen idee. Ik merk dat ik bij mijn browser op het werk, het afsluiten van de browser genoeg is om de melding opnieuw omhoog te laten komen. Bij mij thuis duurt het wat langer heb ik het idee.

[HollowGamer]

Ik wil dezelfde bug(?) ook melden, bij mij komt die melding namelijk elke keer als ik T.net bezoek (Chromium).
Bij andere sites, zoals Github, heb ik dit niet. Wordt die popup automatisch geactiveerd of is dit iets wat er wordt gestuurd bij een sessie controle?

[ACM]

HollowGamer schreef op zaterdag 9 februari 2019 @ 16:58:
Ik wil dezelfde bug(?) ook melden, bij mij komt die melding namelijk elke keer als ik T.net bezoek (Chromium).
Bij andere sites, zoals Github, heb ik dit niet. Wordt die popup automatisch geactiveerd of is dit iets wat er wordt gestuurd bij een sessie controle?

Heb je mijn reactie gelezen? Zoja, wat is er niet duidelijk aan waardoor je deze vraag stelt?

[HollowGamer]

@ACM Inmiddels heb ik de tekst even gelezen, maar ik snap het verhaal nog steeds niet echt goed.
Over welke techniek hebben we het hier? En naar welke ID kijken jullie precies?
De enige manier waar ik mee bekend ben is op opslaan in de web storage of het gebruiken van een cookie.

Is het ook niet een beetje zonde om die bevestiging in je eigen DB op te slaan?
Zeker omdat deze per sessie en browser kan verschillen. Wat gebeurd er als een gebruiker het vervolgens weer weigert?

[ Voor 85% gewijzigd door HollowGamer op 09-02-2019 22:47 ]

[m-vw]

@ACM je verhaal is duidelijk, maar jij weet toch wel of er iets veranderd is bij jullie backend?
Dit heeft jaren goed gewerkt en nu ineens niet meer. Natuurlijk kan het ook aan onze kant zitten, maar voor zover ik weet heb ik niets veranderd.

Telefoon is een Samsung J5 en ik gebruik de standaard browser (v8.2.01.2)

[ACM]

HollowGamer schreef op zaterdag 9 februari 2019 @ 22:38:
@ACM Inmiddels heb ik de tekst even gelezen, maar ik snap het verhaal nog steeds niet echt goed.
Over welke techniek hebben we het hier?

De browser-standaard "web push notifications". Dat is een grotendeels "client side"-techniek, maar je moet het wel uiteindelijk koppelen aan de serverkant van de website.
Wat een belangrijk aspect hiervan is; wij sturen daarbij een encrypted bericht naar google/mozilla/microsoft om die uiteindelijk bij jou terecht te laten komen. Het is dus niet zo dat jouw browser de hele tijd met Tweakers verbonden blijft.

En naar welke ID kijken jullie precies?

In deze context kunnen we helemaal niet naar een id kijken. Effectief begint elke pageview met een blanco stukje kennis voor het wel of niet hebben van toestemming voor webpush en het wel of niet hebben van een referentie waar e.e.a. dan heen gestuurd moet worden.

We moeten daarom elke pageview opnieuw vragen "staat web push voor ons aan?". En daar komt ja of nee op.

Als we daar ja op krijgen (zoals bij jullie) gaan we vervolgens controleren of je browser al is aangemeld omdat je er anders geen notificaties in gaat krijgen.

Dat kunnen we alleen doen door aan de browser te vragen "wat is de web push subscription voor ons?". We kunnen dus niet vragen "is web push subscription X nog actueel?"

We krijgen dan dus een antwoord "dit is de subscription (met wat info)" of domweg "er is geen subscription".

En in jullie geval komt er dus steeds bij de eerstvolgende pageview na het eindigen van je browsersessie "er is geen subscription". Waardoor wij daarna om een nieuwe subscription vragen en die vervolgens bij ons opslaan.

De enige manier waar ik mee bekend ben is op opslaan in de web storage of het gebruiken van een cookie.

Er is veel meer Maar in dit geval moet er op drie plekken wat worden opgeslagen;

• bij ons een referentie naar waar we push berichten naartoe moeten sturen. Dit is een combinatie van een url van google/mozilla/microsoft en aanvullende identifiers om te bewijzen dat we legitiem zijn en een public key om de berichten te versleutelen zodat alleen jouw browser ze kan bekijken.
• een soortgelijke referentie bij de browser-maker zodat ie kan controlere dat ons bericht legitiem is en waar dat dan heen moet
• en ook zoiets in jouw browser o.a. om e.e.a. te controleren en daarna met de private key te onsleutelen

Het lijkt er dus op dat dat laatste steeds vervalt.

Is het ook niet een beetje zonde om die bevestiging in je eigen DB op te slaan?
Zeker omdat deze per sessie en browser kan verschillen.

Het is juist per browser. En het zou niet per sessie moeten verschillen. Maar dat doet het blijkbaar wel. En zoals je hierboven ziet moeten wij wel wat opslaan, omdat we niet permanent een verbinding naar jouw browser open houden wat om allerlei technische redenen ook onhaalbaar zou zijn. Wij moeten dus weten wat we waarheen moeten sturen om het uiteindelijk bij jou terecht te laten komen.

Wat gebeurd er als een gebruiker het vervolgens weer weigert?

Dan verwijderd jouw browser de laatste twee dingen van mijn lijstje en als wij een bericht sturen krijgen we de melding dat ie geweigerd werd. Daarop verwijderen we die specifieke "subscription".

m-vw schreef op zondag 10 februari 2019 @ 08:19:
@ACM je verhaal is duidelijk, maar jij weet toch wel of er iets veranderd is bij jullie backend?
Dit heeft jaren goed gewerkt en nu ineens niet meer. Natuurlijk kan het ook aan onze kant zitten, maar voor zover ik weet heb ik niets veranderd.

Telefoon is een Samsung J5 en ik gebruik de standaard browser (v8.2.01.2)

Bij mijn weten is er niks aan onze kant veranderd. Overigens bestaat de standaard nog geen "jaren" en is onze code sowieso nog maar anderhalf jaar oud

Er is daarna nog wel iets veranderd, maar dat zit 'm vooral in het checken of de bijbehorende notificatie wellicht al in een andere browser gelezen is en niet in het "aanmeld"-deel.

Wat nog erger is, is dat dit ook suggereert dat effectief de push notificaties alleen maar werken zolang je browser-sessie voortduurt. Zodra je browser uitgaat wordt het blijkbaar verwijderd en is dus de werking van push notificaties bij jullie nogal ondermijnd.

Dus we zouden wel via een cookie kunnen bewaren dat we al een subscription voor die specifieke browser hadden, om daarmee te voorkomen dat we die melding steeds opnieuw tonen... Maar dan is dus het eigenlijke probleem niet opgelost; als je dan inderdaad geen push notificaties blijkt te krijgen.

Het kan natuurlijk zijn dat wij het niet helemaal juist hebben geimplementeerd, maar dan zou je toch verwachten dat het bij veel meer mensen fout gaat. En bovendien hebben we domweg de code van Google gevolgd uit mijn eerdere link en voor zover wij kunnen beoordelen geen gekke dingen gedaan.

[ Voor 3% gewijzigd door ACM op 10-02-2019 11:07 ]

[HollowGamer]

@ACM Thanks voor de uitleg.

Heb het Google artikel vluchtig doorgelezen, moet mij maar eens gaan verdiepen in de API. Begrijp nu ook waarom je het inderdaad moet opslaan en hoe de verbinding werkt (d.m.v. subscriber).

Inderdaad heeft het dan ook geen zin om een cookie of webstorage te gebruiken, de sessie is immers niet meer actief of is veranderd.

Vreemd dat ik het bijvoorbeeld bij andere diensten niet krijg, dacht dat GitHub/Reddit ook gebruikte, maar nu we het erover hebben lijkt het erop dat ik geen nieuwe (push)meldingen meer van hun heb gekregen. Denk toch dat dit iets met mijn instellingen te maken heeft, ga dit eens testen.

[ Voor 49% gewijzigd door HollowGamer op 10-02-2019 11:17 ]

[ACM]

HollowGamer schreef op zondag 10 februari 2019 @ 11:13:
Vreemd dat ik het bijvoorbeeld bij andere diensten niet krijg, dacht dat GitHub/Reddit ook gebruikte, maar nu we het erover hebben lijkt het erop dat ik geen nieuwe (push)meldingen meer van hun heb gekregen. Denk toch dat dit iets met mijn instellingen te maken heeft, ga dit eens testen.

Die "pushnotificaties zijn geactiveerd" is iets dat wij zelf hebben verzonnen. Daardoor valt het bij ons op, bij de rest wellicht niet

Mocht je uitvinden wat het is, dan hoor ik dat uiteraard graag van je.

Je kan snel een overzicht zien van de 'service workers' (die nodig zijn om ontvangen push berichten te verwerken) door in je Chrome naar about://serviceworker-internals/ te gaan.
als je dit stukje quote krijg je vast een lelijke html-tag ipv wat ik heb geplaatst

Nog beter is de functie in de developer tools (maar die is op je mobiel vast lastig); dat werkt ook als je niet op Tweakers bent (en dat is in dit geval natuurlijk nodig). Daarvoor moet je het menu rechtsboven openen, dan naar tools -> more tools -> developer tools (op windows is de shortkey ctrl+shift+i). Daarin heb je weer een tabblad "Application" met daarbinnen links de "Service workers". En daarin zie je dan weer een "Service workers from other domains".

Daar kan je e.e.a. ook testen door een bericht te sturen, hoewel de kans dat dat goed werkt klein is. De onze verwacht bijvoorbeeld meer dan wat simpele tekst, dus in plaats van een popupje kreeg ik wat javascript errors

Ik kan helaas geen manier vinden om de in je browser bekende "push subscriptions" te achterhalen.

[ Voor 6% gewijzigd door ACM op 10-02-2019 11:27 ]

[HollowGamer]

@ACM Ik zie het volgende overigens staan op de serviceworker-internals pagina:

code:

Scope: https://tweakers.net/
Registration ID: 118
Navigation preload enabled: false
Navigation preload header length: 4
Active worker:
Installation Status: ACTIVATED
Running Status: STOPPED
Fetch handler existence: DOES_NOT_EXIST
Script: https://tweakers.net/service_worker.js
Version ID: 667
Renderer process ID: 0
Renderer thread ID: -1
DevTools agent route ID: -2
Log:

De developer tools ga ik nog checken.

[WCA]

Intussen komt deze melding elke keer dat ik mijn browser open en tweakers laad naar voren. Het is dus niet meer willekeurig.

[ACM]

De push notificaties werken blijkbaar niet goed in je browser, althans de bijbehorende registratie wordt blijkbaar steeds na het sluiten van je browser weggegooid in plaats van dat ze langdurig bewaard blijven.

Je bent er niet de enige mee, maar getuige de beperkte aantal meldingen in dit topic (en ik heb ook weinig duplicaten of klachten op andere plekken gezien) ben je wel een van de weinigen

Waarom jij dit krijgt weet ik niet, maar in mijn beleving is het een probleem met jouw browser en/of computer die blijkbaar een behoorlijk unieke combinatie van instellingen, plugins en/of overige tools heeft.

De notificatie die we sturen om een (nieuwe) registratie te melden doen we om mensen feedback te geven dat de feature werkt. Bij jou betekent dat effectief dat ie je steeds laat weten dat je een nieuwe inschrijving hebt gekregen.
Met wat moeite kunnen we dat wel verbergen als het al eerder was gebeurt (althans, aannemende dat onze cookies wel blijven bestaan), maar het is dan wel een workaround die het onderliggend probleem dan domweg maskeert en niet oplost. Je gaat alsnog na het sluiten en herstarten van je browser pas weer push notificaties van ons krijgen vanaf het moment dat je weer een keer op Tweakers bent geweest...

Het is heel vervelend dat dit gebeurt, maar voor zover ik kan beoordelen niet iets waar wij wat voor kunnen doen

[WCA]

Het gebeurt op een schone installatie van firefox, op meerdere van mijn machines. Ik snap er niets van.

Op chrome is er niks aan de hand.

't is niet zo heel erg, maar wel opvallend

[ACM]

GreNade schreef op vrijdag 1 maart 2019 @ 23:30:
Het gebeurt op een schone installatie van firefox, op meerdere van mijn machines. Ik snap er niets van.

Dat is inderdaad wel bijzonder.

Die firefox heeft dan nog geen plugins? Geen virusscanners oid geinstalleerd? Gebruik je een via firefox gedeeld profiel of heb je een vers browser profiel dan?

't is niet zo heel erg, maar wel opvallend

Het stoort mij dat we niet weten wat het is Maar er is verdraaid weinig aan te doen lijkt het

[AgamemnonZ]

ACM schreef op vrijdag 1 maart 2019 @ 23:02:
Je bent er niet de enige mee, maar getuige de beperkte aantal meldingen in dit topic (en ik heb ook weinig duplicaten of klachten op andere plekken gezien) ben je wel een van de weinigen

Om maar een duit in het zakje te doen; Ik heb hier ook last van . Dit gebeurt in ieder geval op Ubuntu 14.04 in combinatie met Firefox.

[.oisyn]

ACM schreef op vrijdag 1 maart 2019 @ 23:02:
Het is heel vervelend dat dit gebeurt, maar voor zover ik kan beoordelen niet iets waar wij wat voor kunnen doen

Er is wel iets dat je kunt doen - de melding dat je browser is aangemeld niet pushen . Het is mijns inziens een zinloze melding, en tweakers.net is wat mijn subscriptions betreft ook de enige site die dat doet.

[ACM]

.oisyn schreef op dinsdag 19 maart 2019 @ 16:16:
Er is wel iets dat je kunt doen - de melding dat je browser is aangemeld niet pushen . Het is mijns inziens een zinloze melding, en tweakers.net is wat mijn subscriptions betreft ook de enige site die dat doet.

Maar effectief is het onderliggende probleem dan niet opgelost, alleen verborgen. Want je krijgt dus gewoon geen push messages meer; alleen vanaf het moment dat je Tweakers bezoekt tot het moment dat je je browser sluit (of eerder al?).
Als er dan iets gebeurt terwijl jij slaapt (iig je browser uit staat ) en wij een push message sturen, komt die simpelweg niet aan.

Dat probleem kunnen we niet oplossen, en de melding niet tonen verbergt dat probleem dus eigenlijk alleen maar.

Maar blijkbaar vind iedereen het alleen maar vervelend dat je die melding krijgt, ipv dat je push messages blijkbaar niet goed werken.

Of komen die berichten die tijdens je afwezigheid ontstonden wel aan? Dat is mij nog niet echt duidelijk.
Want dan is er inderdaad vooral iets geks aan de hand met het beheer van de subscription in jullie browsers en is het minder kwalijk om dat stukje te negeren.


Los daarvan: is het ook een zinloze melding als je voor het eerst de boel activeert? Het doel ervan is natuurlijk te testen en te bevestigen dat de door ons ontvangen subscription ook echt werkt en een demo te geven van hoe dat dan eruit ziet.
Browsers helpen niet bepaald mee om ons te laten weten of het al de zoveelste keer is dat de browser een subscription afgeeft, of dat dit pas de eerste keer is. Dit wel inbouwen is daardoor alleen met aanvullende informatieopslag (in localstorage, cookies of evt onze sessies) door ons mogelijk.

Kortom, het is voor ons dan het minste werk om het dan helemaal te verwijderen. Maar als de meerwaarde van het originele doel nog bestaat, is dat wel interessant om nog te bekijken.

[.oisyn]

ACM schreef op dinsdag 19 maart 2019 @ 21:20:
[...]

Maar effectief is het onderliggende probleem dan niet opgelost, alleen verborgen. Want je krijgt dus gewoon geen push messages meer; alleen vanaf het moment dat je Tweakers bezoekt tot het moment dat je je browser sluit (of eerder al?).

Dat maak ik niet op uit de berichten. Het enige wat je krijgt is dat de browser rapporteert dat er geen registratie is. Maar op het moment dat je niet tweakers.net aan het browsen bent loopt de regitratie volgens jullie systeem gewoon en pushen jullie de notificaties. Er is niet gezegd dat die notificaties niet aankomen.

Het zou wel interessant zijn om te weten of @GreNade dus wel notificaties ontvangt in zijn 'offline' tijd.

[ Voor 7% gewijzigd door .oisyn op 19-03-2019 21:24 ]

[WCA]

.oisyn schreef op dinsdag 19 maart 2019 @ 21:21:
[...]

Dat maak ik niet op uit de berichten. Het enige wat je krijgt is dat de browser rapporteert dat er geen registratie is. Maar op het moment dat je niet aan het browsen bent loopt de regitratie volgens jullie systeem gewoon en pushen jullie de notificaties. Er is niet gezegd dat die notificaties niet aankomen.

Het zou wel interessant zijn om te weten of @GreNade dus wel notificaties ontvangt in zijn 'offline' tijd.

Ik ontvang pas tweakers notificaties als ik tweakers die sessie een keer geopend heb volgens mij. Op mijn telefoon ontvang ik ze ook wanneer mijn browser gesloten is.

[.oisyn]

Ah ok, dat ondersteunt wat @ACM zegt. Dan heeft het gewoonweg niet tonen van de melding weinig nut idd

[ACM]

.oisyn schreef op dinsdag 19 maart 2019 @ 21:21:
[...]

Dat maak ik niet op uit de berichten. Het enige wat je krijgt is dat de browser rapporteert dat er geen registratie is. Maar op het moment dat je niet aan het browsen bent loopt de regitratie volgens jullie systeem gewoon en pushen jullie de notificaties. Er is niet gezegd dat die notificaties niet aankomen.

Nou, eerdere opmerkingen in combinatie met wat deductie lijkt daar wel op te duiden.

Dat wij in de database een registratie hebben zegt natuurlijk niet dat die nog geldig is. Het is alleen erg moeilijk om dit na te gaan, want het enige contactmoment met de push service is om er daadwerkelijk een bericht naartoe te sturen. Als wij dan een 4xx response krijgen, verwijderen we de betreffende subscription automatisch.
Dat is verder de enige manier waarop ze automatisch worden verwijderd. Gecombineerd met het feit dat de betreffende gebruikers doorgaans maar weinig subscriptions hebben, concludeerde ik daaruit dat we dan blijkbaar ook 4xx-responses hebben gekregen voor die subscriptions.

Het kan natuurlijk zijn dat er tijdelijk meerdere voor een browser staan en dat we pas na de nieuwe subscription-opslag een oude subscription verwijderen. Maar dat is net zo moeilijk na te gaan.

Al met al is het sowieso afwijkend browsergedrag, want normaliter geven de door ons geteste browsers gewoon "dit is je subscription" in de javascript-aanroep.
Het is wat dat betreft lastig dat het maar bij zo weinig bezoekers voorkomt, want ik heb nu in ieder geval geen idee hoe het te reproduceren zou zijn. En dus kan ik niet in detail achterhalen welk deel er nou mis gaat.

[ACM]

.oisyn schreef op dinsdag 19 maart 2019 @ 21:26:
Ah ok, dat ondersteunt wat @ACM zegt. Dan heeft het gewoonweg niet tonen van de melding weinig nut idd

Nouja, op zich heb je wel een punt dat die meldingen vervelend zijn en in theorie nutteloos kunnen zijn. Het voordeel was wel dat we een probleem aan het licht hebben gebracht.

Alleen doordat we (ik iig) geen idee heb hoe dit opgelost moet worden, is het alsnog niet heel nuttig om ze te blijven tonen

Dan blijft natuurlijk nog wel de vraag over of gebruikers die hier last van hebben niet uiteindelijk beter af zijn door domweg push notificaties helemaal uit te zetten in de betreffende browsers. Dat schept iig geen valse verwachtingen.

[.oisyn]

Ja zo zat ik ook te denken idd. Als je de melding dan nog steeds irritant vindt kun je gewoon de notificaties van t.net blokkeren in die specifieke installatie van de browser.

[Will_M]

Wordt die herhaaldelijk gegenereerde melding niet gewoon veroorzaakt door het wissen van cookies bij een reboot of log-out van de user-sessie op een PC (zakelijke omgeving?) óf eventueel door het actief weigeren van "third party cookies"?

De eerste mogelijkheid is gewoon een logisch gevolg van het wissen van de session cookies, de tweede mogelijkheid zou (eigenlijk) niet voor mogen komen doordat 't wel/niet tonen van die pop-up in een tweakers,net eigen persistent cookie hoort te staan......

[ Voor 5% gewijzigd door Will_M op 19-03-2019 21:49 ]

[ACM]

@wimmel_1 't is wat anders dan cookies. Ik heb geen idee of Chrome desalniettemin een soortgelijk gedrag heeft voor service workers en/of web push subscriptions.

Verder is er zo te zien deze bug bij Chrome/Chromium gemeld, die ruwweg hetzelfde gedrag lijkt te beschrijven bij een andere website.
https://bugs.chromium.org/p/chromium/issues/detail?id=830528

Ik heb daar overigens geimpliceerd dat @GreNade wellicht bereid is mee te helpen de issue te debuggen

[WCA]

ACM schreef op dinsdag 19 maart 2019 @ 21:55:
@wimmel_1 't is wat anders dan cookies. Ik heb geen idee of Chrome desalniettemin een soortgelijk gedrag heeft voor service workers en/of web push subscriptions.

Verder is er zo te zien deze bug bij Chrome/Chromium gemeld, die ruwweg hetzelfde gedrag lijkt te beschrijven bij een andere website.
https://bugs.chromium.org/p/chromium/issues/detail?id=830528

Ik heb daar overigens geimpliceerd dat @GreNade wellicht bereid is mee te helpen de issue te debuggen

Ja hoor, geen probleem

[WCA]

Ik moet me alleen wel eventjes heel erg gaan schamen.

Oorzaak is gevonden, het blijkt de "facebook container" instelling te zijn die dit veroorzaakt. Nu is het ding: deze wordt bij een schone installatie nogal in je gezicht geduwd, en ik had zodanig niet door dat dit uberhaupt een plugin was.

Ik keek bij mijn schone installatie eens tussen mijn addons, en toen stond daar zowaar een plugin tussen die ik niet bewust (als plugin) geinstalleerd had.

Weer een mysterie de wereld uit, excuses voor het verdoen van jullie tijd.....

[ACM]

Nouja, ook die plugin hoort dat niet te veroorzaken. Wellicht kan je dat nog in het chromium bug ticket melden? Je bent dan vast niet de enige met die plugin.

[EnigmA-X]

Ook ik had hetzelfde probleem als omschreven. Al een dag of 10, dus besloot maar eens wat te gaan zoeken of ik de enige was.

Idem verhaal met de Facebook container plugin, geinstalleerd op Firefox 75.0, Windows 10.

Heb zojuist plugin verwijderd. Probleem met de push-melding van Tweakers is abrupt agelopen.

[ACM]

Blijkbaar had niemand van ons - mijzelf inclusief - er aan gedacht een bugmelding bij Firefox te doen. Dat is ondertussen wel gebeurt door iemand die er ook last van heeft.