查看 Chrome 控制台是否打开
我正在使用这个小脚本来查明 Firebug 是否打开:
if (window.console && window.console.firebug) {
//is open
};
并且它运行良好。现在我搜索了半个小时,想找到一种方法来检测Google Chrome内置的Web开发者控制台是否打开,但我找不到任何提示。
这:
if (window.console && window.console.chrome) {
//is open
};
不起作用。
编辑:
看来无法检测Chrome控制台是否打开。但是有一个“黑客”有效,但有一些缺点:
- 当控制台未对接时将不起作用
- 当控制台在页面加载时打开时将不起作用
所以,我现在要选择 Unsigned 的答案,但如果有人提出了一个绝妙的主意,欢迎他仍然回答,我改变选定的答案!谢谢!
I am using this little script to find out whether Firebug is open:
if (window.console && window.console.firebug) {
//is open
};
And it works well. Now I was searching for half an hour to find a way to detect whether Google Chrome's built-in web developer console is open, but I couldn't find any hint.
This:
if (window.console && window.console.chrome) {
//is open
};
doesn't work.
EDIT:
So it seems that it is not possible to detect whether the Chrome console is open. But there is a "hack" that works, with some drawbacks:
- will not work when console is undocked
- will not work when console is open on page load
So, I am gonna choose Unsigned´s answer for now, but if some1 comes up with a brilliant idea, he is welcome to still answer and I change the selected answer! Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(25)
将之前的答案留在下面以了解历史背景。
调试器(2022)
虽然不是万无一失,但另一个答案中的这种基于调试器的方法似乎仍然有效。
requestAnimationFrame(2019 年末)
目前 Muhammad Umer 的方法适用于 Chrome 78,并具有检测关闭和打开事件的附加优势。
function toString (2019)
归功于 Overcl9ck 对此答案的评论。用空函数对象替换正则表达式
/./
仍然有效。regex toString (2017-2018)
由于最初的询问者似乎不再存在,并且这仍然是公认的答案,因此添加此解决方案以提高可见性。功劳归于 Antonin Hildebrand 的 评论 zswang的答案 。该解决方案利用了这样一个事实:除非控制台打开,否则不会对记录的对象调用
toString()
。console.profiles (2013)
更新:
console.profiles
已从 Chrome 中删除。该解决方案不再有效。感谢 Paul Irish 在 使用探查器发现 DevTools:
window.innerHeight (2011)
这个其他选项可以检测页面加载后打开的停靠检查器,但无法检测未停靠的检查器,或者检查器是否在页面加载时已打开。也存在一些误报的可能性。
Leaving previous answers below for historical context.
Debugger (2022)
While not fool-proof, this debugger-based approach in another answer does appear to still work.
requestAnimationFrame (Late 2019)
Currently Muhammad Umer's approach works on Chrome 78, with the added advantage of detecting both close and open events.
function toString (2019)
Credit to Overcl9ck's comment on this answer. Replacing the regex
/./
with an empty function object still works.regex toString (2017-2018)
Since the original asker doesn't seem to be around anymore and this is still the accepted answer, adding this solution for visibility. Credit goes to Antonin Hildebrand's comment on zswang's answer. This solution takes advantage of the fact that
toString()
is not called on logged objects unless the console is open.console.profiles (2013)
Update:
console.profiles
has been removed from Chrome. This solution no longer works.Thanks to Paul Irish for pointing out this solution from Discover DevTools, using the profiler:
window.innerHeight (2011)
This other option can detect the docked inspector being opened, after the page loads, but will not be able to detect an undocked inspector, or if the inspector was already open on page load. There is also some potential for false positives.
Chrome 65+ (2018)
演示:https://jsbin.com/cecuzeb/edit?output(2018年3月更新-16)
package: https://github.com/zswang/jdetects
当打印“Element” Chrome开发者时工具将得到它的 ID
另一个版本(来自评论)
打印一个常规变量:
Chrome 65+ (2018)
demo: https://jsbin.com/cecuzeb/edit?output (Update at 2018-03-16)
package: https://github.com/zswang/jdetects
When printing “Element” Chrome developer tools will get its id
Another version (from comments)
Print a regular variable:
非常可靠的黑客
基本上在属性上设置一个吸气剂并将其记录在控制台中。显然,只有当控制台打开时才能访问该东西。
https://jsfiddle.net/gcdfs3oo/44/
Very Reliable hack
Basically set a getter on property and log it in console. Apparently the thing gets accessed only when console is open.
https://jsfiddle.net/gcdfs3oo/44/
我创建了 devtools-detect 来检测 DevTools 何时打开:
您还可以监听一个事件:
它在以下情况下不起作用: DevTools 已取消对接。但是,可以与 Chrome/Safari/Firefox DevTools 和 Firebug 配合使用。
I created devtools-detect which detects when DevTools is open:
You can also listen to an event:
It doesn't work when DevTools is undocked. However, works with the Chrome/Safari/Firefox DevTools and Firebug.
演示:https://jsbin.com/cateqeyono/edit?html,output
Demo: https://jsbin.com/cateqeyono/edit?html,output
-----更新:------
这是一个老问题,有许多很好的答案,并且在一段时间内发挥了作用。截至2022 年 9 月 5 日的当前最佳答案是 @starball https://stackoverflow.com/a/ 68494829/275333
顺便说一句,自从我发布它以来,我的答案仍然有效,只是让它始终准确有点困难。在关闭/打开控制台的情况下,单击我的演示中的“手动基准测试”链接,看看我的意思 - 总是有很大的差异。
---------------------------------
我找到了一种方法来判断 Chrome 控制台是否打开。
它仍然是一个黑客,但它更加准确,并且无论控制台是否脱离底座都可以工作。
基本上,在控制台关闭的情况下运行此代码大约需要约 100 微秒,而在控制台打开时,则需要大约两倍的时间约 200 微秒。
(1 毫秒 = 1000 微秒)
我已经写了更多关于它的内容 这里。
演示位于此处。
------ Update: ------
This is an old question with many great answers that worked for a while. The current best answer as of September 5th 2022 is by @starball https://stackoverflow.com/a/68494829/275333
Btw, my answer is still working the same since I've posted it, it's just a bit difficult to make it always accurate. Click on the "Manual Benchmark" link in my demo with the console closed/opened to see what I mean - there is always a big difference.
----------------------
I found a way to tell if the Chrome Console is opened or not.
It’s still a hack but it’s way more accurate and will work whether the console is undocked or not.
Basically running this code with the console closed takes about ~100 microseconds and while the console is opened it takes about twice as much ~200 microseconds.
(1 millisecond = 1000 microsecond)
I’ve written more about it here.
Demo is here.
似乎有一些常见的解决方案类别:
debugger
语句结合使用。棘手的部分是找到一种方法,使计时器不会被 事件循环队列,以及调试器语句暂停其运行的线程的执行这一事实。还有一个挑战是用户可以根据具体情况或禁用全部来禁用常规调试器语句。以下是我使用
调试器
方法对特定问题的解决方案。 IE。当主线程在启发式计时器之间运行长任务时,避免误报,避免调试器语句阻塞主线程,并防止禁用调试器语句。注意:我认为没有办法阻止用户禁用所有调试器断点,这可能是最好的。工作原理
当开发工具打开并且线程遇到调试语句时,Chrome 浏览器就会进入调试状态。
eval
语句中以防止用户禁用它)。我已经在 GitHub 上发布了一个参考实现(由我编写)这里< /a>、和一个演示在这里。
优点
console.log
方法不同,这可以适用于控制台的多次打开-关闭,而不会向控制台发送大量消息。缺点
There seem to be a few common classes of solutions:
debugger
statement. The tricky part is to find a way so that the timers can't get messed up by long running tasks in the event loop queue, and the fact that the debugger statement pauses execution of the thread it runs on. There's also the challenge that regular debugger statements can be disabled by the user on a case-by-case or disable-all basis.What follows is my solution to the specific problems with the
debugger
approach. Ie. Avoid false positives when the main thread runs a long task between a heuristic timer, avoid thedebugger
statement from blocking the main thread, and prevent disabling the debugger statement. Note: I don't think there is a way to prevent a user from disabling all debugger breakpoints, and that is probably for the best.How It Works
The Chrome browser enters debugging when devtools are open and a thread encounters a debugging statement.
eval
statement to prevent the user from disabling it).I've published a reference implementation (authored by me) here on GitHub, and a demo here.
Pros
console.log
approaches, this can work for multiple open-closes of the console without spamming the console with messages.Cons
我发现新方法在 Chrome 89 上工作,
使用 console.profile、setInterval 和函数 toString
在 safari 中,它不起作用。
在 chrome 89 以下,我无法检查它是否有效。
I found new methods work at Chrome 89
Using console.profile, setInterval and function toString
In safari, it doesn't works.
Below chrome 89, i can't check whether it works.
Chrome 开发者工具实际上只是 WebKit 的 WebCore 库的一部分。所以这个问题适用于 Safari、Chrome 和任何其他 WebCore 消费者。
如果存在解决方案,它将基于 WebKit Web 检查器打开和关闭时 DOM 中的差异。不幸的是,这是一种先有鸡还是先有蛋的问题,因为当检查器关闭时我们无法使用检查器来观察 DOM。
您可以做的就是编写一些 JavaScript 来转储整个 DOM 树。然后在检查器打开时运行一次,在检查器关闭时运行一次。 DOM 中的任何差异都可能是 Web 检查器的副作用,我们可以使用它来测试用户是否正在检查。
这个链接对于 DOM 转储脚本来说是一个好的开始,但是您需要转储整个
DOMWindow
对象,而不仅仅是document
。更新:
看起来现在有办法做到这一点。查看 Chrome 检查器检测器
The Chrome developer tools is really just a part of WebKit's WebCore library. So this question applies to Safari, Chrome, and any other WebCore consumers.
If a solution exists, it'll be based off a difference in the DOM when the WebKit web inspector is open and when it's closed. Unfortunately, this is a kind of a chicken and egg problem because we can't use the inspector to observe the DOM when the inspector is closed.
What you may be able to do is write a bit of JavaScript to dump the entire DOM tree. Then run it once when the inspector is open, and once when the inspector is closed. Any difference in the DOM is probably a side-effect of the web inspector, and we may be able to use it to test if the user is inspecting or not.
This link is a good start for a DOM dumping script , but you'll want to dump the entire
DOMWindow
object, not justdocument
.Update:
Looks like there's a way to do this now. Check out Chrome Inspector Detector
我写了一篇关于此的博客文章: http://nepjua.org/check -if-browser-console-is-open/
可以检测是否停靠或取消停靠
I wrote a blog post about this: http://nepjua.org/check-if-browser-console-is-open/
It can detect whether it's docked or undocked
有一种棘手的方法可以检查它是否具有“选项卡”权限的扩展:
您也可以检查它是否为您的页面打开:
There is a tricky way to check it for extensions with 'tabs' permission:
Also you can check if it open for your page:
Muhammad Umer 的方法对我有用,而且我正在使用 React,所以我决定制作一个 hooks 解决方案:
注意:当我搞乱了它,很长一段时间都不起作用,我不明白为什么。我已经删除了
console.dir(element);
这对于它的工作原理至关重要。我删除了大多数非描述性控制台操作,因为它们只是占用空间并且通常对于该功能来说不是必需的,所以这就是为什么它对我不起作用。使用它:
我希望这可以帮助任何使用 React 的人。如果有人想对此进行扩展,我希望能够在某个时刻停止无限循环(因为我没有在每个组件中使用它)并找到一种保持控制台干净的方法。
Muhammad Umer's approach worked for me, and I'm using React, so I decided to make a hooks solution:
NOTE: When I was messing with it, it didn't work for the longest time and I couldn't figure out why. I had deleted
console.dir(element);
which is critical to how it works. I delete most non-descriptive console actions since they just take up space and aren't usually necessary to the function, so that was why it wasn't working for me.To use it:
I hope this helps anyone using React. If anyone wants to expand on this, I would like to be able stop the infinite loop at some point (since I don't use this in every component) and to find a way to keep the console clean.
Javascript 检测开发者工具控制台打开
从 2022 年 2 月 2 日起
未固定/固定/键盘快捷键)Javascript Detect Developer Tools Console Opening
Working from 2/2/2022
Undocked/Docked/Keyboard shortcuts)当浏览器的 DevTools 打开时,断点标记为“debugger;”只要您不停用断点,就会附加。
这是检查调试器是否启用的代码:
注意:如果使用 CSP,则您需要将
worker-src 'unsafe-inline'
添加到 CSP 策略,或者将上面的工作线程源代码移动到 CSP 允许的资源并更改workerUrl< /code> 到该资源。
When a browser's DevTools is open, breakpoints marked by 'debugger;' will be attached as long as you don't deactivate breakpoints.
So here is the code to check if debugger is enabled:
Note: if CSP is used then you need either to add
worker-src 'unsafe-inline'
to CSP policy or to move worker source code above to a CSP-allowed resource and changeworkerUrl
to that resource.您也可以尝试以下操作: https://github.com/sindresorhus/devtools-detect
Also you can try this: https://github.com/sindresorhus/devtools-detect
如果您是在开发过程中做事情的开发人员。看看这个 Chrome 扩展程序。它可以帮助您检测 Chrome Devtoos 何时打开或关闭。
https://chrome.google.com/webstore/detail/devtools-status-Detector/pmbbjdhohceladenbdjjoejcanjijoaa?authuser=1
此扩展程序可帮助 Javascript 开发人员检测 Chrome Devtools 在当前情况下打开或关闭的情况页。
当 Chrome Devtools 关闭/打开时,扩展程序将在 window.document 元素上引发名为“devtoolsStatusChanged”的事件。
这是示例代码:
If you are developers who are doing stuff during development. Check out this Chrome extension. It helps you detect when Chrome Devtoos is opened or closed.
https://chrome.google.com/webstore/detail/devtools-status-detector/pmbbjdhohceladenbdjjoejcanjijoaa?authuser=1
This extension helps Javascript developers detect when Chrome Devtools is open or closed on current page.
When Chrome Devtools closes/opens, the extension will raise a event named 'devtoolsStatusChanged' on window.document element.
This is example code:
这里的一些答案将在 Chrome 65 中停止工作。这是一种定时攻击替代方案,在 Chrome 中运行得非常可靠,并且比
toString()
方法更难缓解。不幸的是,它在 Firefox 中并不那么可靠。Some answers here will stop working in Chrome 65. Here's a timing attack alternative that works pretty reliably in Chrome, and is much harder to mitigate than the
toString()
method. Unfortunately it's not that reliable in Firefox.至于 Chrome/77.0.3865.75 的 2019 版本不起作用。 toString 立即调用,无需打开 Inspector。
As for Chrome/77.0.3865.75 a version of 2019 not works. toString invokes immediately without Inspector opening.
使用包 dev-tools 中的这个包
isDevToolsOpened()
函数- 监控除 Firefox 外,它在所有浏览器中都能按预期工作。
use this package
isDevToolsOpened()
function from the package dev-tools-monitorwhich works as expected in all browsers except for firefox.
您可以捕捉打开开发的事件。通过将事件侦听器添加到打开该工具的键盘快捷键来使用该工具。这不是“黑客”,而且 100% 的时间都有效。
它不会捕获的唯一情况是当用户用鼠标手动打开它时。所以这是一个“部分解决方案”,也许对某人有用。
打开开发者工具的键盘快捷键:
You can catch the event of opening the dev. tools by adding event listeners to the keyboard shortcuts with which it opens. This is not a "hack" and it works 100% of the time.
The only case it won't catch is when the user opens it manually with mouse. So it is a "partial solution" perhaps it is useful for somebody.
Keyboard shortcuts to open Developer Tools:
计时解决方案(适用于对接和未对接)
它有点侵入性,但不如调试器陷阱那么多
Timing solution (works for docked and undocked)
It is a bit intrusive but not as much as the debugger trap
在 2024 年,如果 devtools 控制台打开,您始终可以检查显示哪些窗口属性。
目前这些是
所以脚本是这样的:
要验证它只需将其放入 setTimeout 并关闭控制台,然后再打开它并查看它打印的内容。
In 2024 you can always just check which window properties appear if devtools console is open.
Currently those are
So the script is something like:
To verify it just put it in setTimeout and close console and then open it back and see what it printed.
我意识到这不是一个通用的解决方案,但可能会对遇到类似情况的人有所帮助:
我在开发工具打开时遇到了 JavaScript 测试失败的问题。测试的代码监听
focusin
事件,并且这些事件仅在文档具有显式焦点时触发。我的解决方法是在
!document.hasFocus()
时使规范失败并给出解释。I realize this is not a general solution, but might help someone with a similiar case:
I had a problem with a JavaScript test failing while the DevTools are open. The tested code listened to
focusin
events, and those only fire if the document has explicit focus.My workaround was to fail the spec with an explanation when
!document.hasFocus()
.启用调试模式开/关功能的最佳方法是默认在 localStorage 中设置一个标志
'debugMode'='off'
-然后,在 Local Storage 中更改它开发时手动打开浏览器 -
然后在代码中使用以下条件在“打开”时执行不同的操作 -
Best way to have Debug-Mode on/off feature is to set a flag
'debugMode'='off'
in localStorage by default -Then, change it in Local Storage of browser manually to 'on' while development -
Then use below condition in code to do differrent action if it's 'on' -