Перанос пашырэнняў проксі паміж Chrome і Firefox
Firefox і Chrome прапануюць падобныя па назвах API пашырэнняў, але з рознымі мадэлямі канфігурацыі. Пераносьце палітыку маршрутызацыі, а не толькі прастору імён.
Перайменаванне chrome у browser не з'яўляецца поўным пераносам пашырэння проксі.
Канфігурацыя фіксаванага сервера ў Chrome выкарыстоўвае аб'ект рэжыму і правілаў. Firefox прапануе уласны інтэрфейс глабальных налад проксі і API proxy.onRequest для кожнага запыту. Падобныя назвы не робяць іх уваходныя аб'екты ўзаемазаменнымі.
Пачніце з палітыкі, якую хочаце выразіць: адзін фіксаваны канчатковы пункт, канфігурацыя PAC або маршрут, які выбіраецца асобна для кожнага запыту. Затым выкарыстоўвайце інтэрфейс, дакументаваны для кожнага браўзера.
Слухач Firefox для кожнага запыту можа вяртаць інфармацыю пра проксі з кода пашырэння. Ён патрабуе дазволу проксі і адпаведнага доступу да хоста для перахопленых запытаў. Гэта іншая архітэктура, чым капіраванне аб'екта налад фіксаванага сервера Chrome і спадзяванне, што браўзер распазнае кожнае поле.
Праверце таксама падтрымоўваную версію Firefox і патрабаванні да manifest. Старыя прыклады з proxy.register() апісваюць ранейшы API і не павінны быць асновай сучаснага пашырэння.
Трымайце агульныя даныя палітыкі асобна ад адаптацыі пад канкрэтны браўзер. Тэсты і дыягностыка павінны паказваць маршрут, выбраны для пэўнага пункту прызначэння ў кожным браўзеры, уключаючы наўмысны прамы вынік. Сапраўдны manifest і выклік API без памылак — гэта толькі пачатак.