Недавний Firefox ломает существующее преобразованное расширение Chrome - PullRequest
0 голосов
/ 15 ноября 2018

У меня есть расширение на основе Chrome, которое исправно работает в Chrome 26 - Chrome 70. Оно продолжает работать точно так же, как в Chrome в Firefox 47, 48, 49, но теперь не работает в FF / DevEdition 64.

Понятия не имею, с чего начать, какую несовместимость FF в более поздних версиях вводили / ломали базовые функции, которые работали в 47,48,49?Будут оценены любые указатели (даже ссылка на архивные версии между ними, чтобы я мог взять запасной компьютер и найти точную версию, где он выходит из строя).

update: это код демона (background pg)который открывает интерфейс GUI (выдержка):

    var fireflyID = 0;
    /* ... */     
             // msgpath 'class' [creates a bridge between the SDK (the GUI)
             // and the tab it monitor/analyses/debugs ...
    var msgpath = function(pathid, pathname, tabID, url, opener, reply) {
         /* ... */
         this.pathname = pathname;
         this.sdk.path = url;
         this.tab.tabID = tabID;
         this.tab.port  = chrome.tabs.connect(tabID);
         this.tab.port.onMessage.addListener(handleSCRMsg);
         /* ... */
         this.connect  = function() {    //opening handshake with contentscr
             this.tab.port.postMessage( {"msgtype":"connect" /* ... */};
             };
         this.accept   = function() {    //handshake accepted, open the sdk...
             var fireflyURL;
             fireflyURL = chrome.runtime.getURL(this.sdk.path);

                 // this works in Chrome26-Chrome70 (latest version)
                 // and Firefox 47-55, it opens the panel in FF56+,
                 // applies the title, but never displays the content?
                 // and yes .getURL() does add the right 'protocol' to the url

             this.sdk.wdw = chrome.windows.create( {
                 "url" : fireflyURL + 
                          "?portname=" + this.pathname + ";opener=",
                 "width" : 980,
                 "height" : 720,
                 "type" : "panel"
                 }); 
             };
         /* ... */
         };
     /* ... */
                            // msg from content-script...
     var handeSCRMsg = function(msg) {
         var mpath = null;

         if (msg.msgpath) {
             mpath = msgpaths[msg.msgpath];
             /* ... */                     // content scr accepts connection
                if (msg.msgtype == "accept")
                    mpath.accept();  // msgpath object 'class' from above
             /* ... */                     // go open the sdk and splice the port connections
             }
         };    

     var handleCTRLMsg = function(msg) {
         /* ... */
         if (msg.msgtype == "open") {
             pathid = fireflyID++;
             pathname = "firefly"+pathid;
             mpath = new msgpath(pathid, pathname, msg.tabID,
                                         msg.path, msg.parent, msg.reply);
             mpath.connect();
         };

      // wake up on pageAction (extension icon click)
      chrome.pageAction.onClicked.addListener( function(tab) {
          /* ... */
          msg.tabID = tab.id;
          msg.path  = "sdkfirefly.html";
          handleCTRLMsg(msg);
          };
                         // content scr posts msg to daemon to tell daemon
                         // that dflibg dataflow library is in application                
                         // 'tab' and it is ok to enable pageAction/icon
      chrome.runtime.onMessage.addListener ( function (msg, sender) {
          /* ... */
          tab  = sender.tab;
          if (msg.msgtype == "activate")
              chrome.pageAction.show(tab.id);
          }

и показывает соответствующую логику / поток сообщений.Это довольно простой материал, и, поскольку он работает во многих других случаях, я не совсем понимаю, что делать дальше.

Дальнейшее обновление: в журнале консоли отображаются некоторые ошибки XML-файла, связанные с внутренним firefox - все остальное вуровень предупреждения (ff не , обращающий внимание на номер версии манифеста, или неправильная обработка манифеста) или ошибка ff [например, он жалуется на отсутствие «стиля браузера», но он присутствует в page_action какэто должно быть;затем он жалуется на background.persistent, но его нет и все равно не относится к FF ...] Ничто из этого не является существенным, поскольку суть проблемы заключается в следующем:

При дальнейшем тестировании:
Расширение загружается и работает в FF47-FF55 на всех платформах.По-видимому, не завершает загрузку в FF56 + в Windows, но загружается и работает, как ожидается, в FF47-FF64 в Linux.

Интерфейс расширения [в конечном итоге] загружается в Win10 / FF56 (i7-7700 / 3.6), ноЗагрузка (ожидание) занимает более 12 минут, чтобы FF загрузил его (из-за чего он выглядит неработоспособным - в Linux это занимает 1/2 секунды или меньше [на amd X4 860K], или 40 секунд +/- в Win7 (i7).-6700 / 3.4). Часть этого заключается в том, что что-то действительно не так с механизмом FF ipc, используемым в качестве базового уровня для обмена сообщениями между вкладкой и страницей расширения - >> требуется 14 секунд для сообщения в оба конца междуGUI-> daemon-> content-script-> library, library-> content_script-> daemon-> GUI (всего шесть прыжков) в win10 / FF, но в linux он принимает только миллисекунды.

Похоже, что-торадикально изменился между FF55 и FF56 + на платформах Window $ 64bit. У кого-нибудь есть подсказка о разнице или обойти что-то другое, кроме механизма ipc порта? Спасибо

1 Ответ

0 голосов
/ 02 декабря 2018

После обширного тестирования проблема, как представляется, заключается в том, как FF56 и более новый интерфейс с Windows7 / 10 для доступа к компонентам расширения - IFF расширение было загружено из смонтированного общего ресурса NAS / Samba или NFS. Почему это также влияет на ipc - полная загадка.

Решение состоит в том, чтобы скопировать расширение с устройства NAS или смонтированного общего ресурса Samba / NFS. на физически локальный жесткий диск и оттуда временно загрузите расширение.

...