最近的 Firefox 破坏了现有的转换 Chrome 扩展

Question

我有一个基于 Chrome 的扩展程序，它在 Chrome 26 到 Chrome 70 中一直运行良好。它继续像在 Firefox 中的 Chrome 中一样工作47、48、49，但现在已损坏 FF/DevEdition 64.

我不知道从哪里开始看 FF 以后版本有什么不兼容 introduced/broke 在 47、48、49 中工作的基本功能？任何指针都将不胜感激（甚至 link 到两者之间的存档版本，这样我就可以抓住一个备用的'puter并找到它失败的确切版本）。

更新：这是打开GUI界面的守护进程（后台pg）代码（摘录）：

    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);
          }

这显示了相关的 logic/msg 流程。这是非常基本的东西，因为它适用于许多其他情况我对接下来要调查的地方感到很困惑。

进一步更新：控制台日志显示了一些 firefox 内部 xml 错误 - 其他所有内容都处于警告级别（ff not 注意清单版本号，或错误处理清单）或 ff 错误 [例如，它抱怨 "browser-style" 丢失，但它在 page_action 中，因为它应该是；然后它抱怨 background.persistent 但那不存在并且不适用于 FF...] None 这是 material 因为以下似乎是问题的症结所在：

经进一步测试：
扩展在所有平台上以 FF47-FF55 加载和运行。在 Windows 的 FF56+ 中似乎未完成加载，但在 Linux.

的 FF47-FF64 中按预期加载和运行

扩展 gui [最终] 在 Win10/FF56 (i7-7700/3.6) 中加载，但 FF 需要（等待）超过 12 分钟才能加载它（这使它看起来损坏了-- 在 Linux [在 amd X4 860K] 中需要 1/2 秒或更少，或者在 Win7 (i7-6700/3.4) 中需要 40 秒 +/-。部分原因是有一些东西用作选项卡和扩展页面之间消息传递基础层的 FF ipc 机制确实有问题 -->> GUI->daemon->content-script->library、library 之间的往返 msg 需要 14 秒->content_script->daemon->GUI（总共六跳）在 win10/FF 中，但在 linux.

中只需要毫秒

在 Window$64 位平台上，FF55 和 FF56+ 之间似乎发生了根本性的变化。有没有人知道差异的线索，或者使用端口 ipc 机制以外的其他方法的解决方法？谢谢

Answer 1

经过广泛测试后，问题似乎是 FF56 和更新版本如何与 Windows7/10 交互以访问扩展的组件 - 如果扩展是从 NAS/Samba 或 NFS 安装共享加载的。为什么这对 ipc 也有影响完全是个谜。

解决方案是从 NAS 设备或 Samba/NFS 挂载的共享中复制扩展到物理本地硬盘驱动器并从那里临时加载扩展。

最近的 Firefox 破坏了现有的转换 Chrome 扩展

Recent Firefox breaks existing converted Chrome extension

javascript

firefox-addon-webextensions