在生产版本中启用/禁用console.log

时间:2017-06-03 02:34:50

标签: google-chrome-extension firefox-webextensions

基于标志我想在生产版本中启用或禁用console.log。但我不想向用户公开该选项,因为这样每个人都会询问它并浪费我的时间。

如果我允许通过选项对话框将这样的标志存储在用户首选项中,那么在加载这些首选项之前,我的代码将喷出console.log输出,直到加载该标志来自铬存储。

我可以使用扩展程序创建调试标志cookie,但不幸的是我的扩展程序可以在许多站点上运行。

如果我在生产版本中完全禁用console.log但是当客户遇到问题时,那时我将无法查看console.log来调试它。所以这是不可行的。

我的扩展程序是否可以从第一行知道每次运行扩展时需要绕过console.log(包括 BG脚本内容脚本选项对话框)?

1 个答案:

答案 0 :(得分:1)

没有什么可以在所有上下文中设置一个你不必异步获取的值。你将不得不处理它。

主要方法:等待信息。延迟执行直到可用。

处理这种情况的常用方法是将所有可能需要信息的处理放入程序流中,该程序流以对storage.*的异步调用的回调开始。这是正常的,并且预期使用异步编程。在几乎所有情况下,这都是你应该如何处理的。

在后台上下文(后台脚本/事件页面,弹出窗口,选项页面等)中等待脚本的信息应该很容易。对于除后台脚本以外的任何内容,这些脚本几乎都是基于用户交互的功能,这意味着获取storage.local的延迟应该是微不足道的。如果不是,您可以随时将值复制到后台页面中的变量,该变量可以由后台上下文中的任何脚本直接同步访问(请参阅:Communicate between scripts in the background context (background script, browser action, page action, options page, etc.))。

对于后台脚本,您还可以使用同步的localStorage。但是,数据不会在所有情况下都可用。

对于内容脚本,需要延迟异步数据可能意味着提前缩短注入时间。换句话说,您可能需要在document_start而不是document_idledocument_end注入(run_atrunAt)。然后,您需要延迟剩余的处理,直到文档准备好/加载完毕为止。

对于已在document_start

加载的内容脚本

特别针对console.log()

对于您的具体问题,通过console.log()输出,您可以将通常发送到console.log()的输出排队,直到您将数据从异步调用返回到storage.local。获得数据后,您可以A)输出队列中的所有内容并将所有内容设置为正常输出,或者B)将所有内容转储到队列中并设置要删除的每个调用。

只需覆盖console.log处的函数指针指向队列函数,正常console.log()或null函数,即可轻松完成所有这些操作。因此,无需更改脚本其余部分调用console.log()的方式。如果您在console中使用其他功能,它会变得更复杂,但console.log()很容易(我已经完成了它,出于性能原因在测试期间,而不是针对此特定问题)

一般情况下(即对于以后不能排队的事情)

这个充其量只是非常重要的。对于通过 manifest.json content_scripts条目注入的脚本,没有好的解决方案。

对代码进行分区

将代码分成必须立即完成的内容以及可以等待回调的内容。这可能需要您操作页面,以使正常加载过程中的某些操作延迟到您获得信息之后。您实际需要做的事情将根据您想要完成的内容而有所不同。最好的解决方案可能最终是在配置发生变化的一方或另一方面出现代码错误,然后在获得指示应该是另一种方式的配置信息之后将其修补到应该是什么。< / p>

例如,一个旨在阻止JavaScript在页面中运行但具有允许的脚本/域的白名单的扩展可以继续并在插入时删除所有<script>个元素。然后,一旦配置信息可用,就可以将允许的<scripts>重新插入DOM中。

使用chrome.tabs.executeScript()

使用chrome.tabs.executeScript(),您可以在注入主脚本之前注入带有配置信息的构造脚本。这些脚本位于相同的上下文中,因此第一个脚本可以设置包含配置信息的变量。有关详细信息,请参阅:Pass a parameter to a content script injected using chrome.tabs.executeScript()

后台脚本(执行chrome.tabs.executeScript())与选项卡的进程(实际注入脚本的进程)处于不同的进程中。因此,当完全注入脚本时,由于具有多个过程的异步性质,这将是不确定的。这意味着您无法100%保证在将初始HTML加载到DOM之前注入脚本。您可以通常之前注入,但并非总是如此。

何时注射尽可能早的时间有点复杂。其中一个问题是,如果在加载新页面的过程中过早地调用tabs.executeScript(),则不会在新页面中进行注入。我的测试(我需要回去重做,因为我相信它可以改进)表明:

相关:{{3}}