Im vorherigen Artikel haben wir über die neue Javascript-Engine gesprochen in dem die Leute von Mozilla für die nächste Version von Firefox 70 gearbeitet haben, die im nächsten Monat Oktober eintreffen wird (Sie können den Hinweis in der lesen folgenden Link). In diesem Artikel werden wir über die Ankündigung von Mozilla sprechen Informationen zur Verwendung von Firefox-Add-Ons basierend auf der WebExtensions-API in dem die Mozilla-Entwickler ihre Position bekannt gaben in welchem Sie beabsichtigen nicht, die bevorstehende dritte Ausgabe des Chrome Plugin Manifests vollständig zu verfolgen.
Damit machen sie insbesondere das bekannt, Firefox unterstützt weiterhin den Blockierungsmodus der webRequest-APIDies ermöglicht es Ihnen, akzeptierte Inhalte im laufenden Betrieb zu ändern und ist in Werbeblockern und Inhaltsfiltersystemen gefragt.
Die Hauptidee des Übergangs zur WebExtensions-API war die Vereinheitlichung der Plugin-Entwicklungstechnologie für Firefox und Chrome. Daher ist Firefox in seiner aktuellen Form fast 100% kompatibel mit der aktuellen zweiten Version des Chrome-Manifests.
Das Manifest definiert eine Liste der bereitgestellten Funktionen und Ressourcen für die Ergänzungen. Aufgrund der Einführung restriktiver Maßnahmen, die von l negativ wahrgenommen werdenEntwickler von Plugins in der dritten Version des Manifests, Mozilla wird die Praxis des vollständigen Befolgens des Manifests aufgeben und keine Änderungen an Firefox übertragen die die Plugin-Kompatibilität verletzen.
Beachten Sie, dass Google trotz aller Einwände plant, die Unterstützung für Chrome in dem Modus einzustellen, der den WebRequest-API-Modus blockiert, ihn auf den schreibgeschützten Modus beschränkt und neue Funktionen zum Filtern deklarativer Inhalte der deklarativen NetRequest-API bietet.
Wenn Sie mit der webRequest-API Ihre eigenen Controller mit vollem Zugriff auf Netzwerkanforderungen verbinden und den Datenverkehr im laufenden Betrieb ändern können, bietet die neue deklarative NetRequest-API Zugriff auf eine sofort einsatzbereite universelle integrierte Filter-Engine, die unabhängig verarbeitet Die Blockierungsregeln erlauben nicht die Verwendung eigener Filteralgorithmen und erlauben nicht, dass sich komplexe Regeln basierend auf Bedingungen überlappen.
Mozilla prüft auch die Bequemlichkeit der Portierung auf Firefox, um einige der anderen Änderungen zu unterstützen. aus der dritten Version des Chrome-Manifests, die die Plugin-Unterstützung verletzt:
- La Übergang zur Hinrichtung von Servicemitarbeitern In Form von Hintergrundprozessen müssen die Entwickler den Code einiger Ergänzungen ändern.
Obwohl die neue Methode hinsichtlich der Leistung optimaler ist, erwägt Mozilla, die Unterstützung für das Ausführen von Hintergrundseiten beizubehalten. - Neues granulares Berechtigungsanforderungsmodell: Das Plugin kann nicht sofort für alle Seiten aktiviert werden (die Berechtigung "all_urls" wird entfernt), funktioniert jedoch nur im Kontext der aktiven Registerkarte, dh der Benutzer muss die Plugin-Funktion für jede Site bestätigen. In diesem Segment sucht Mozilla nach Möglichkeiten, die Zugriffskontrolle zu verbessern, ohne den Benutzer ständig abzulenken.
- Änderung in der abwicklungsübergreifenden Antragsbearbeitung: Gemäß dem neuen Manifest gelten für Inhaltsverarbeitungsskripte dieselben Berechtigungsbeschränkungen wie für die Hauptseite, in die diese Skripte eingefügt werden (wenn die Seite beispielsweise keinen Zugriff auf die Standort-API hat, werden die Skript-Plugins nicht abgerufen diesen Zugang entweder). Die Änderung soll in Firefox implementiert werden.
- Verbot der Ausführung von Code, der von externen Servern heruntergeladen wurde (Wir sprechen über Situationen, in denen ein Plugin externen Code lädt und ausführt). Firefox verwendet bereits externe Codeblockierung, und Mozilla-Entwickler setzen diesen Schutz gerne durch, indem sie zusätzliche Code-Download-Tracking-Techniken verwenden, die in der dritten Version des Manifests angeboten werden.
Quelle: https://blog.mozilla.org