Related
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!
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.
var devtools = function() {};
devtools.toString = function() {
if (!this.opened) {
alert("Opened");
}
this.opened = true;
}
console.log('%c', devtools);
// devtools.opened will become true if/when the console is opened
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.
var devtools = /./;
devtools.toString = function() {
if (!this.opened) {
alert("Opened");
}
this.opened = true;
}
console.log('%c', devtools);
// devtools.opened will become true if/when the console is opened
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:
function isInspectOpen() {
console.profile();
console.profileEnd();
if (console.clear) {
console.clear();
}
return console.profiles.length > 0;
}
function showIfInspectIsOpen() {
alert(isInspectOpen());
}
<button onClick="showIfInspectIsOpen()">Is it open?</button>
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.
window.onresize = function() {
if ((window.outerHeight - window.innerHeight) > 100) {
alert('Docked inspector was opened');
}
}
Chrome 65+ (2018)
r = /./
r.toString = function () {
document.title = '1'
}
console.log('%c', r);
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
var checkStatus;
var element = document.createElement('any');
element.__defineGetter__('id', function() {
checkStatus = 'on';
});
setInterval(function() {
checkStatus = 'off';
console.log(element);
console.clear();
}, 1000);
Another version (from comments)
var element = new Image();
Object.defineProperty(element, 'id', {
get: function () {
/* TODO */
alert('囧');
}
});
console.log('%cHello', element);
Print a regular variable:
var r = /./;
r.toString = function() {
document.title = 'on';
};
console.log(r);
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/
var checkStatus;
var indicator = document.querySelector('#devtool-status');
var element = new Image();
Object.defineProperty(element, 'id', {
get: function() {
checkStatus='on';
throw new Error("Dev tools checker");
}
});
requestAnimationFrame(function check() {
checkStatus = 'off';
console.dir(element);
indicator.className = checkStatus;
requestAnimationFrame(check);
});
.on{
color:limegreen;
}
.off{
color:red;
}
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.7.1/css/all.css" integrity="sha256-DVK12s61Wqwmj3XI0zZ9MFFmnNH8puF/eRHTB4ftKwk=" crossorigin="anonymous" />
<p>
<ul>
<li>
dev toolbar open: icon is <span class="on">green</span>
</li>
<li>
dev toolbar closed: icon is <span class="off">red</span>
</li>
</ul>
</p>
<div id="devtool-status"><i class="fas fa-7x fa-power-off"></i></div>
<br/>
<p><b>Now press F12 to see if this works for your browser!</b></p>
I created devtools-detect which detects when DevTools is open:
console.log('is DevTools open?', window.devtools.open);
You can also listen to an event:
window.addEventListener('devtoolschange', function (e) {
console.log('is DevTools open?', e.detail.open);
});
It doesn't work when DevTools is undocked. However, works with the Chrome/Safari/Firefox DevTools and Firebug.
------ 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 #david-fong 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.
console.log(1);
console.clear();
(1 millisecond = 1000 microsecond)
I’ve written more about it here.
Demo is here.
console.log(Object.defineProperties(new Error, {
message: {get() {alert('Chrome/Firefox')}},
toString: {value() {(new Error).stack.includes('toString#')&&alert('Safari')}}
}));
Demo: https://jsbin.com/cateqeyono/edit?html,output
There seem to be a few common classes of solutions:
Rely on detecting resizing of the screen when the devtools appear (this doesn't work when the devtools/console are opened as a separate window)
Intercept certain user actions that can bring up the devtools/console such as right click menu, F12, Ctrl+Shift+C, etc. This can't cover UI mechanisms that are in the browser chrome that aren't detectable by the page.
Log something to the console and rely on browser-specific behaviour for lazy, fancy printing. Historically, these seem to not be highly reliable, but they're nice and simple. If you want them to work repeatedly in the same browsing session, you'll probably have to accept some degree of console spam.
Use timing heuristics with the 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 the debugger 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.
Main thread sends a message to a webworker thread.
Worker thread replies with an opening heartbeat.
Main thread reacts by starting a timer to expect the closing heartbeat.
Worker thread's message handler encounters a debugger statement (optionally wrapped in an eval statement to prevent the user from disabling it).
If devtools are closed, the worker will immediately send an acknowledgement to the main thread, and the main thread will conclude that devtools are closed.
If devtools are opened, the worker will enter a debugging session, and the main thread will notice that the Worker has not responded sufficiently quickly, concluding that the debugger must be open. The main thread will not be blocked by the worker's debugging session, but it's timeout response will be blocked by any heavy processing in the main thread ahead of it in the event queue.
I've published a reference implementation (authored by me) here on GitHub, and a demo here.
Pros
Unlike screen-size-change-detection approaches, this works when the console is in a separate window.
Unlike user-action-interception approaches, this works regardless of what user action brings up the console.
Unlike console.log approaches, this can work for multiple open-closes of the console without spamming the console with messages.
Unlike basic timer-debugger approaches, the detection should never trigger false positives due to busy threads (main thread, or other workers), the debugger statement is in the worker instead of the main thread, so the main thread won't get blocked, and the eval-debugger statement prevents disabling that specific debugger statement.
Cons
The user can disable all breakpoints, which will disable this method of detection.
The eval-wrapped debugger statement won't work on sites which disable eval via their Content Security Policy, in which case only a regular debugger statement can be used.
I found new methods work at Chrome 89
Using console.profile, setInterval and function toString
var devtools = function() {};
devtools.toString = function() {
alert('NOPE!!')
return '-'
}
setInterval(()=>{
console.profile(devtools)
console.profileEnd(devtools)
}, 1000)
In safari, it doesn't works.
Below chrome 89, i can't check whether it works.
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 just document.
Update:
Looks like there's a way to do this now. Check out Chrome Inspector Detector
There is a tricky way to check it for extensions with 'tabs' permission:
chrome.tabs.query({url:'chrome-devtools://*/*'}, function(tabs){
if (tabs.length > 0){
//devtools is open
}
});
Also you can check if it open for your page:
chrome.tabs.query({
url: 'chrome-devtools://*/*',
title: '*example.com/your/page*'
}, function(tabs){ ... })
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
function isConsoleOpen() {
var startTime = new Date();
debugger;
var endTime = new Date();
return endTime - startTime > 100;
}
$(function() {
$(window).resize(function() {
if(isConsoleOpen()) {
alert("You're one sneaky dude, aren't you ?")
}
});
});
var div = document.createElement('div');
Object.defineProperty(div,'id',{get:function(){
document.title = 'xxxxxx'
}});
setTimeout(()=>console.log(div),3000)
Muhammad Umer's approach worked for me, and I'm using React, so I decided to make a hooks solution:
const useConsoleOpen = () => {
const [consoleOpen, setConsoleOpen] = useState(true)
useEffect(() => {
var checkStatus;
var element = new Image();
Object.defineProperty(element, "id", {
get: function () {
checkStatus = true;
throw new Error("Dev tools checker");
},
});
requestAnimationFrame(function check() {
checkStatus = false;
console.dir(element); //Don't delete this line!
setConsoleOpen(checkStatus)
requestAnimationFrame(check);
});
}, []);
return consoleOpen
}
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:
import React from 'react'
const App = () => {
const consoleOpen = useConsoleOpen()
return (
<div className="App">
<h1>{"Console is " + (consoleOpen ? "Open" : "Closed")}</h1>
</div>
);
}
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 Detect Developer Tools Console Opening
Working from 2/2/2022
Chrome Version 97 (Developer Tools Undocked/Docked/Keyboard shortcuts)
Edge Version 97 (Developer Tools Undocked/Docked/Keyboard shortcuts)
FireFox Version 96.0.03 (Developer Tools Undocked/Docked/Keyboard shortcuts)
Safari ?
FireBug Detection (Developer Tools)
// Prevent Right Click (Optional)
document.addEventListener('contextmenu', function(event) {
event.preventDefault();
}, true);
// DevTools Opened Script
function DevToolsOpened() {
alert("Developer Tools Opened");
}
// Detect DevTools (Chrome/Edge)
// https://stackoverflow.com/a/67148898/9498503 (SeongJun)
var devtools = function() {};
devtools.toString = function() {
DevToolsOpened();
return '-';
}
setInterval(()=>{
console.profile(devtools);
console.profileEnd(devtools);
if (console.clear) {
console.clear();
}
}, 1000);
// Detect DevTools (FireFox)
if (navigator.userAgent.toLowerCase().indexOf('firefox') > -1){
// Detect Resize (Chrome/Firefox/Edge Works) but (Triggers on Zoom In Chrome and Zoom Out FireFox)
window.onresize = function() {
if ((window.outerHeight - window.innerHeight) > 100 || (window.outerWidth - window.innerWidth) > 100) {
DevToolsOpened();
}
}
}
// Detect Fire Bug
if (window.console && window.console.firebug || console.assert(1) === '_firebugIgnore') {
DevToolsOpened();
};
// Detect Key Shortcuts
// https://stackoverflow.com/a/65135979/9498503 (hlorand)
window.addEventListener('keydown', function(e) {
if (
// CMD + Alt + I (Chrome, Firefox, Safari)
e.metaKey == true && e.altKey == true && e.keyCode == 73 ||
// CMD + Alt + J (Chrome)
e.metaKey == true && e.altKey == true && e.keyCode == 74 ||
// CMD + Alt + C (Chrome)
e.metaKey == true && e.altKey == true && e.keyCode == 67 ||
// CMD + Shift + C (Chrome)
e.metaKey == true && e.shiftKey == true && e.keyCode == 67 ||
// Ctrl + Shift + I (Chrome, Firefox, Safari, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 73 ||
// Ctrl + Shift + J (Chrome, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 74 ||
// Ctrl + Shift + C (Chrome, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 67 ||
// F12 (Chome, Firefox, Edge)
e.keyCode == 123 ||
// CMD + Alt + U, Ctrl + U (View source: Chrome, Firefox, Safari, Edge)
e.metaKey == true && e.altKey == true && e.keyCode == 85 ||
e.ctrlKey == true && e.keyCode == 85
) {
DevToolsOpened();
}
});
Also you can try this: https://github.com/sindresorhus/devtools-detect
// check if it's open
console.log('is DevTools open?', window.devtools.open);
// check it's orientation, null if not open
console.log('and DevTools orientation?', window.devtools.orientation);
// get notified when it's opened/closed or orientation changes
window.addEventListener('devtoolschange', function (e) {
console.log('is DevTools open?', e.detail.open);
console.log('and DevTools orientation?', e.detail.orientation);
});
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:
function addEventListener(el, eventName, handler) {
if (el.addEventListener) {
el.addEventListener(eventName, handler);
} else {
el.attachEvent('on' + eventName,
function() {
handler.call(el);
});
}
}
// Add an event listener.
addEventListener(document, 'devtoolsStatusChanged', function(e) {
if (e.detail === 'OPENED') {
// Your code when Devtools opens
} else {
// Your code when Devtools Closed
}
});
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.
addEventListener("load", () => {
var baseline_measurements = [];
var measurements = 20;
var warmup_runs = 3;
const status = document.documentElement.appendChild(document.createTextNode("DevTools are closed"));
const junk = document.documentElement.insertBefore(document.createElement("div"), document.body);
junk.style.display = "none";
const junk_filler = new Array(1000).join("junk");
const fill_junk = () => {
var i = 10000;
while (i--) {
junk.appendChild(document.createTextNode(junk_filler));
}
};
const measure = () => {
if (measurements) {
const baseline_start = performance.now();
fill_junk();
baseline_measurements.push(performance.now() - baseline_start);
junk.textContent = "";
measurements--;
setTimeout(measure, 0);
} else {
baseline_measurements = baseline_measurements.slice(warmup_runs); // exclude unoptimized runs
const baseline = baseline_measurements.reduce((sum, el) => sum + el, 0) / baseline_measurements.length;
setInterval(() => {
const start = performance.now();
fill_junk();
const time = performance.now() - start;
// in actual usage you would also check document.hasFocus()
// as background tabs are throttled and get false positives
status.data = "DevTools are " + (time > 1.77 * baseline ? "open" : "closed");
junk.textContent = "";
}, 1000);
}
};
setTimeout(measure, 300);
});
As for Chrome/77.0.3865.75 a version of 2019 not works. toString invokes immediately without Inspector opening.
const resultEl = document.getElementById('result')
const detector = function () {}
detector.toString = function () {
resultEl.innerText = 'Triggered'
}
console.log('%c', detector)
<div id="result">Not detected</div>
use this package isDevToolsOpened() function from the package dev-tools-monitor
which works as expected in all browsers except for firefox.
Force a colorized welcome message, each time the console is opened.
// Force a colorized welcome message
// each time the console is opened.
(() => {
w = new Function()
w.toString = () => { (!this.z) ? console.log("%cWelcome to the console\n %cMaster password:\n %c window.password = ' ... ':", "color: white; font-size: 20px; background-color: blue", "color: white; font-size: 16px; background-color: red;margin 20px 0", "background: #222; color: #bada55") : this.z = true
}
console.log('%c', w)
})()
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.
<script>
function devToolsOpened(e){
alert("devtools opened");
// uncomment to prevent opening dev.tools:
// e.preventDefault();
}
window.addEventListener('keydown', function(e) {
if (
// CMD + Alt + I (Chrome, Firefox, Safari)
e.metaKey == true && e.altKey == true && e.keyCode == 73 ||
// CMD + Alt + J (Chrome)
e.metaKey == true && e.altKey == true && e.keyCode == 74 ||
// CMD + Alt + C (Chrome)
e.metaKey == true && e.altKey == true && e.keyCode == 67 ||
// CMD + Shift + C (Chrome)
e.metaKey == true && e.shiftKey == true && e.keyCode == 67 ||
// Ctrl + Shift + I (Chrome, Firefox, Safari, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 73 ||
// Ctrl + Shift + J (Chrome, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 74 ||
// Ctrl + Shift + C (Chrome, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 67 ||
// F12 (Chome, Firefox, Edge)
e.keyCode == 123 ||
// CMD + Alt + U, Ctrl + U (View source: Chrome, Firefox, Safari, Edge)
e.metaKey == true && e.altKey == true && e.keyCode == 85 ||
e.ctrlKey == true && e.keyCode == 85
){
devToolsOpened(e);
}
});
</script>
Keyboard shortcuts to open Developer Tools:
Chrome: https://developers.google.com/web/tools/chrome-devtools/shortcuts
Firefox: https://developer.mozilla.org/hu/docs/Tools
Safari: https://developer.apple.com/library/archive/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/KeyboardShortcuts/KeyboardShortcuts.html
Edge: https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/shortcuts
Timing solution (works for docked and undocked)
It is a bit intrusive but not as much as the debugger trap
var opened = false;
var lastTime = Date.now();
const interval = 50;
const threshold = 30;
setInterval(() => {
let delta = Date.now() - lastTime;
if (delta > interval + threshold) {
document.title = "P3nis";
opened = true;
}
lastTime = Date.now();
if (!opened) {
debugger;
}
}, interval)
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:
let workerUrl = 'data:application/javascript;base64,' + btoa(`
self.addEventListener('message', (e) => {
if(e.data==='hello'){
self.postMessage('hello');
}
debugger;
self.postMessage('');
});
`);
function checkIfDebuggerEnabled() {
return new Promise((resolve) => {
let fulfilled = false;
let worker = new Worker(workerUrl);
worker.onmessage = (e) => {
let data = e.data;
if (data === 'hello') {
setTimeout(() => {
if (!fulfilled) {
resolve(true);
worker.terminate();
}
}, 1);
} else {
fulfilled = true;
resolve(false);
worker.terminate();
}
};
worker.postMessage('hello');
});
}
checkIfDebuggerEnabled().then((result) => {
if (result) {
alert('browser DevTools is open');
}else{
alert('browser DevTools is not open, unless you have deactivated breakpoints');
}
});
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 change workerUrl to that resource.
Best way to have Debug-Mode on/off feature is to set a flag 'debugMode'='off' in localStorage by default -
localStorage.setItem('debugMode', 'off');
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' -
if(localStorage.getItem('debugMode') === 'on'){
//do something 1
}else {
//do something 2
}
I have 3 buttons with hover states which makes a little tooltip appear to describe the button. They work fine but on touchs screen they do not disappear after the user clicks on the button.
So I've tried a few js scripts for checking if a device is a touch device or not. They almost work but they also when I test on IE11 it also gets detected as a touch device. Chrome & Firefox do not get mistaken as a touch device.
Any sugestions?
Her is what I've tried
/*****************************
TOUCH DEVICES HOVER FIX START
****************************/
// http://stackoverflow.com/a/4819886/1814446
function isTouchDevice() {
return 'ontouchstart' in window // works on most browsers
|| 'onmsgesturechange' in window; // works on ie10
};
// http://www.stucox.com/blog/you-cant-detect-a-touchscreen/#poke-it
var hasTouch;
window.addEventListener('touchstart', function setHasTouch () {
hasTouch = true;
// Remove event listener once fired, otherwise it'll kill scrolling
// performance
window.removeEventListener('touchstart', setHasTouch);
}, false);
// https://github.com/Modernizr/Modernizr/blob/master/feature-detects/touchevents.js
define(['Modernizr', 'prefixes', 'testStyles'], function( Modernizr, prefixes, testStyles ) {
// Chrome (desktop) used to lie about its support on this, but that has since been rectified: http://crbug.com/36415
Modernizr.addTest('touchevents', function() {
var bool;
if(('ontouchstart' in window) || window.DocumentTouch && document instanceof DocumentTouch) {
bool = true;
} else {
var query = ['#media (',prefixes.join('touch-enabled),('),'heartz',')','{#modernizr{top:9px;position:absolute}}'].join('');
testStyles(query, function( node ) {
bool = node.offsetTop === 9;
});
}
return bool;
});
});
if(bool===true) {
console.log('Touch Device'); //your logic for touch device
jQ( "#btn-1, #btn-2, #btn-3" ).click(function() {
jQ("#btn-1 .tooltip").css('opacity', '0');
jQ("#btn-2 .tooltip").css('opacity', '0');
jQ("#btn-3 .tooltip").css('opacity', '0');
});
}
else {
//your logic for non touch device
}
For IE10+ you can utilize "window.navigator.msMaxTouchPoints"
example code
function isIETouch ()
{
return window.navigator.msMaxTouchPoints == undefined ? false : window.navigator.msMaxTouchPoints;
}
I am trying to make a button that would toggle (on/off) HTML5 fullscreen on a certain website.
After reading plenty of documentation, it appears there still are some inconsistencies among how browsers treat certain properties for it.
I went for kind of "cross-browser" approach which does work in Firefox and Safari/MacOS, partially works in Safari/Windows and totally fails to work in Chrome and Opera.
Some castrated code snippets:
// class init
initialize: function() {
this.elmButtonFullscreen = $('fullscreen');
this.elmButtonFullscreen.on('click', this.onClickFullscreen.bindAsEventListener(this));
},
// helper methods
_launchFullScreen: function(element) {
if(element.requestFullScreen) { element.requestFullScreen(); }
else if(element.mozRequestFullScreen) { element.mozRequestFullScreen(); }
else if(element.webkitRequestFullScreen) { element.webkitRequestFullScreen(); }
},
_cancelFullScreen: function() {
if(document.cancelFullScreen) { document.cancelFullScreen(); }
else if(document.mozCancelFullScreen) { document.mozCancelFullScreen(); }
else if(document.webkitCancelFullScreen) { document.webkitCancelFullScreen(); }
},
_isFullScreen: function() {
fullScreen = document.fullscreenEnabled || document.mozFullscreenEnabled || document.webkitFullscreenEnabled ? true : false;
if(this.debug) console.log('Fullscreen enabled? ' + fullScreen);
return fullScreen;
},
// callbacks
onClickFullscreen: function(e) {
e.stop();
if(this._isFullScreen()) this._cancelFullScreen();
else this._launchFullScreen(document.documentElement);
}
function goFullScreen() {
const el = document.documentElement,
rfs = el.requestFullScreen
|| el.webkitRequestFullScreen
|| el.mozRequestFullScreen
|| el.msRequestFullscreen
rfs.call(el)
}
document.querySelector('#full-screen-button')
.addEventListener('click', () => {
goFullScreen()
})
Keep in mind that requesting fullScreen needs to be done via a user-triggered event such as a click event - mousedown,mouseup etc..
Changing the 1st line of _isFullScreen function to
fullScreen = document.fullscreenEnabled || document.mozFullscreenEnabled || document.webkitFullscreenEnabled ? true : false;
Does the trick (at least for Firefox, Chrome and Safari on Mac and Windows)
Based on what I found on Mozilla's Developer Network the function for Webkit is actually spelt slightly different.
document.webkitRequestFullscreen with a lowercase "s" for screen.
And from W3 spec, it is meant to be with a lowercase "s".
On the MDN link they say:
Note: The specification uses the label, "Fullscreen" as in "requestFullscreen" or "fullscreenEnabled" - without a capital 's'. The implementation described here and other prefixed implementations may use a capital 'S'.
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!
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.
var devtools = function() {};
devtools.toString = function() {
if (!this.opened) {
alert("Opened");
}
this.opened = true;
}
console.log('%c', devtools);
// devtools.opened will become true if/when the console is opened
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.
var devtools = /./;
devtools.toString = function() {
if (!this.opened) {
alert("Opened");
}
this.opened = true;
}
console.log('%c', devtools);
// devtools.opened will become true if/when the console is opened
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:
function isInspectOpen() {
console.profile();
console.profileEnd();
if (console.clear) {
console.clear();
}
return console.profiles.length > 0;
}
function showIfInspectIsOpen() {
alert(isInspectOpen());
}
<button onClick="showIfInspectIsOpen()">Is it open?</button>
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.
window.onresize = function() {
if ((window.outerHeight - window.innerHeight) > 100) {
alert('Docked inspector was opened');
}
}
Chrome 65+ (2018)
r = /./
r.toString = function () {
document.title = '1'
}
console.log('%c', r);
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
var checkStatus;
var element = document.createElement('any');
element.__defineGetter__('id', function() {
checkStatus = 'on';
});
setInterval(function() {
checkStatus = 'off';
console.log(element);
console.clear();
}, 1000);
Another version (from comments)
var element = new Image();
Object.defineProperty(element, 'id', {
get: function () {
/* TODO */
alert('囧');
}
});
console.log('%cHello', element);
Print a regular variable:
var r = /./;
r.toString = function() {
document.title = 'on';
};
console.log(r);
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/
var checkStatus;
var indicator = document.querySelector('#devtool-status');
var element = new Image();
Object.defineProperty(element, 'id', {
get: function() {
checkStatus='on';
throw new Error("Dev tools checker");
}
});
requestAnimationFrame(function check() {
checkStatus = 'off';
console.dir(element);
indicator.className = checkStatus;
requestAnimationFrame(check);
});
.on{
color:limegreen;
}
.off{
color:red;
}
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.7.1/css/all.css" integrity="sha256-DVK12s61Wqwmj3XI0zZ9MFFmnNH8puF/eRHTB4ftKwk=" crossorigin="anonymous" />
<p>
<ul>
<li>
dev toolbar open: icon is <span class="on">green</span>
</li>
<li>
dev toolbar closed: icon is <span class="off">red</span>
</li>
</ul>
</p>
<div id="devtool-status"><i class="fas fa-7x fa-power-off"></i></div>
<br/>
<p><b>Now press F12 to see if this works for your browser!</b></p>
I created devtools-detect which detects when DevTools is open:
console.log('is DevTools open?', window.devtools.open);
You can also listen to an event:
window.addEventListener('devtoolschange', function (e) {
console.log('is DevTools open?', e.detail.open);
});
It doesn't work when DevTools is undocked. However, works with the Chrome/Safari/Firefox DevTools and Firebug.
------ 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 #david-fong 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.
console.log(1);
console.clear();
(1 millisecond = 1000 microsecond)
I’ve written more about it here.
Demo is here.
console.log(Object.defineProperties(new Error, {
message: {get() {alert('Chrome/Firefox')}},
toString: {value() {(new Error).stack.includes('toString#')&&alert('Safari')}}
}));
Demo: https://jsbin.com/cateqeyono/edit?html,output
There seem to be a few common classes of solutions:
Rely on detecting resizing of the screen when the devtools appear (this doesn't work when the devtools/console are opened as a separate window)
Intercept certain user actions that can bring up the devtools/console such as right click menu, F12, Ctrl+Shift+C, etc. This can't cover UI mechanisms that are in the browser chrome that aren't detectable by the page.
Log something to the console and rely on browser-specific behaviour for lazy, fancy printing. Historically, these seem to not be highly reliable, but they're nice and simple. If you want them to work repeatedly in the same browsing session, you'll probably have to accept some degree of console spam.
Use timing heuristics with the 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 the debugger 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.
Main thread sends a message to a webworker thread.
Worker thread replies with an opening heartbeat.
Main thread reacts by starting a timer to expect the closing heartbeat.
Worker thread's message handler encounters a debugger statement (optionally wrapped in an eval statement to prevent the user from disabling it).
If devtools are closed, the worker will immediately send an acknowledgement to the main thread, and the main thread will conclude that devtools are closed.
If devtools are opened, the worker will enter a debugging session, and the main thread will notice that the Worker has not responded sufficiently quickly, concluding that the debugger must be open. The main thread will not be blocked by the worker's debugging session, but it's timeout response will be blocked by any heavy processing in the main thread ahead of it in the event queue.
I've published a reference implementation (authored by me) here on GitHub, and a demo here.
Pros
Unlike screen-size-change-detection approaches, this works when the console is in a separate window.
Unlike user-action-interception approaches, this works regardless of what user action brings up the console.
Unlike console.log approaches, this can work for multiple open-closes of the console without spamming the console with messages.
Unlike basic timer-debugger approaches, the detection should never trigger false positives due to busy threads (main thread, or other workers), the debugger statement is in the worker instead of the main thread, so the main thread won't get blocked, and the eval-debugger statement prevents disabling that specific debugger statement.
Cons
The user can disable all breakpoints, which will disable this method of detection.
The eval-wrapped debugger statement won't work on sites which disable eval via their Content Security Policy, in which case only a regular debugger statement can be used.
I found new methods work at Chrome 89
Using console.profile, setInterval and function toString
var devtools = function() {};
devtools.toString = function() {
alert('NOPE!!')
return '-'
}
setInterval(()=>{
console.profile(devtools)
console.profileEnd(devtools)
}, 1000)
In safari, it doesn't works.
Below chrome 89, i can't check whether it works.
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 just document.
Update:
Looks like there's a way to do this now. Check out Chrome Inspector Detector
There is a tricky way to check it for extensions with 'tabs' permission:
chrome.tabs.query({url:'chrome-devtools://*/*'}, function(tabs){
if (tabs.length > 0){
//devtools is open
}
});
Also you can check if it open for your page:
chrome.tabs.query({
url: 'chrome-devtools://*/*',
title: '*example.com/your/page*'
}, function(tabs){ ... })
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
function isConsoleOpen() {
var startTime = new Date();
debugger;
var endTime = new Date();
return endTime - startTime > 100;
}
$(function() {
$(window).resize(function() {
if(isConsoleOpen()) {
alert("You're one sneaky dude, aren't you ?")
}
});
});
var div = document.createElement('div');
Object.defineProperty(div,'id',{get:function(){
document.title = 'xxxxxx'
}});
setTimeout(()=>console.log(div),3000)
Muhammad Umer's approach worked for me, and I'm using React, so I decided to make a hooks solution:
const useConsoleOpen = () => {
const [consoleOpen, setConsoleOpen] = useState(true)
useEffect(() => {
var checkStatus;
var element = new Image();
Object.defineProperty(element, "id", {
get: function () {
checkStatus = true;
throw new Error("Dev tools checker");
},
});
requestAnimationFrame(function check() {
checkStatus = false;
console.dir(element); //Don't delete this line!
setConsoleOpen(checkStatus)
requestAnimationFrame(check);
});
}, []);
return consoleOpen
}
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:
import React from 'react'
const App = () => {
const consoleOpen = useConsoleOpen()
return (
<div className="App">
<h1>{"Console is " + (consoleOpen ? "Open" : "Closed")}</h1>
</div>
);
}
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 Detect Developer Tools Console Opening
Working from 2/2/2022
Chrome Version 97 (Developer Tools Undocked/Docked/Keyboard shortcuts)
Edge Version 97 (Developer Tools Undocked/Docked/Keyboard shortcuts)
FireFox Version 96.0.03 (Developer Tools Undocked/Docked/Keyboard shortcuts)
Safari ?
FireBug Detection (Developer Tools)
// Prevent Right Click (Optional)
document.addEventListener('contextmenu', function(event) {
event.preventDefault();
}, true);
// DevTools Opened Script
function DevToolsOpened() {
alert("Developer Tools Opened");
}
// Detect DevTools (Chrome/Edge)
// https://stackoverflow.com/a/67148898/9498503 (SeongJun)
var devtools = function() {};
devtools.toString = function() {
DevToolsOpened();
return '-';
}
setInterval(()=>{
console.profile(devtools);
console.profileEnd(devtools);
if (console.clear) {
console.clear();
}
}, 1000);
// Detect DevTools (FireFox)
if (navigator.userAgent.toLowerCase().indexOf('firefox') > -1){
// Detect Resize (Chrome/Firefox/Edge Works) but (Triggers on Zoom In Chrome and Zoom Out FireFox)
window.onresize = function() {
if ((window.outerHeight - window.innerHeight) > 100 || (window.outerWidth - window.innerWidth) > 100) {
DevToolsOpened();
}
}
}
// Detect Fire Bug
if (window.console && window.console.firebug || console.assert(1) === '_firebugIgnore') {
DevToolsOpened();
};
// Detect Key Shortcuts
// https://stackoverflow.com/a/65135979/9498503 (hlorand)
window.addEventListener('keydown', function(e) {
if (
// CMD + Alt + I (Chrome, Firefox, Safari)
e.metaKey == true && e.altKey == true && e.keyCode == 73 ||
// CMD + Alt + J (Chrome)
e.metaKey == true && e.altKey == true && e.keyCode == 74 ||
// CMD + Alt + C (Chrome)
e.metaKey == true && e.altKey == true && e.keyCode == 67 ||
// CMD + Shift + C (Chrome)
e.metaKey == true && e.shiftKey == true && e.keyCode == 67 ||
// Ctrl + Shift + I (Chrome, Firefox, Safari, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 73 ||
// Ctrl + Shift + J (Chrome, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 74 ||
// Ctrl + Shift + C (Chrome, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 67 ||
// F12 (Chome, Firefox, Edge)
e.keyCode == 123 ||
// CMD + Alt + U, Ctrl + U (View source: Chrome, Firefox, Safari, Edge)
e.metaKey == true && e.altKey == true && e.keyCode == 85 ||
e.ctrlKey == true && e.keyCode == 85
) {
DevToolsOpened();
}
});
Also you can try this: https://github.com/sindresorhus/devtools-detect
// check if it's open
console.log('is DevTools open?', window.devtools.open);
// check it's orientation, null if not open
console.log('and DevTools orientation?', window.devtools.orientation);
// get notified when it's opened/closed or orientation changes
window.addEventListener('devtoolschange', function (e) {
console.log('is DevTools open?', e.detail.open);
console.log('and DevTools orientation?', e.detail.orientation);
});
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:
function addEventListener(el, eventName, handler) {
if (el.addEventListener) {
el.addEventListener(eventName, handler);
} else {
el.attachEvent('on' + eventName,
function() {
handler.call(el);
});
}
}
// Add an event listener.
addEventListener(document, 'devtoolsStatusChanged', function(e) {
if (e.detail === 'OPENED') {
// Your code when Devtools opens
} else {
// Your code when Devtools Closed
}
});
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.
addEventListener("load", () => {
var baseline_measurements = [];
var measurements = 20;
var warmup_runs = 3;
const status = document.documentElement.appendChild(document.createTextNode("DevTools are closed"));
const junk = document.documentElement.insertBefore(document.createElement("div"), document.body);
junk.style.display = "none";
const junk_filler = new Array(1000).join("junk");
const fill_junk = () => {
var i = 10000;
while (i--) {
junk.appendChild(document.createTextNode(junk_filler));
}
};
const measure = () => {
if (measurements) {
const baseline_start = performance.now();
fill_junk();
baseline_measurements.push(performance.now() - baseline_start);
junk.textContent = "";
measurements--;
setTimeout(measure, 0);
} else {
baseline_measurements = baseline_measurements.slice(warmup_runs); // exclude unoptimized runs
const baseline = baseline_measurements.reduce((sum, el) => sum + el, 0) / baseline_measurements.length;
setInterval(() => {
const start = performance.now();
fill_junk();
const time = performance.now() - start;
// in actual usage you would also check document.hasFocus()
// as background tabs are throttled and get false positives
status.data = "DevTools are " + (time > 1.77 * baseline ? "open" : "closed");
junk.textContent = "";
}, 1000);
}
};
setTimeout(measure, 300);
});
As for Chrome/77.0.3865.75 a version of 2019 not works. toString invokes immediately without Inspector opening.
const resultEl = document.getElementById('result')
const detector = function () {}
detector.toString = function () {
resultEl.innerText = 'Triggered'
}
console.log('%c', detector)
<div id="result">Not detected</div>
use this package isDevToolsOpened() function from the package dev-tools-monitor
which works as expected in all browsers except for firefox.
Force a colorized welcome message, each time the console is opened.
// Force a colorized welcome message
// each time the console is opened.
(() => {
w = new Function()
w.toString = () => { (!this.z) ? console.log("%cWelcome to the console\n %cMaster password:\n %c window.password = ' ... ':", "color: white; font-size: 20px; background-color: blue", "color: white; font-size: 16px; background-color: red;margin 20px 0", "background: #222; color: #bada55") : this.z = true
}
console.log('%c', w)
})()
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.
<script>
function devToolsOpened(e){
alert("devtools opened");
// uncomment to prevent opening dev.tools:
// e.preventDefault();
}
window.addEventListener('keydown', function(e) {
if (
// CMD + Alt + I (Chrome, Firefox, Safari)
e.metaKey == true && e.altKey == true && e.keyCode == 73 ||
// CMD + Alt + J (Chrome)
e.metaKey == true && e.altKey == true && e.keyCode == 74 ||
// CMD + Alt + C (Chrome)
e.metaKey == true && e.altKey == true && e.keyCode == 67 ||
// CMD + Shift + C (Chrome)
e.metaKey == true && e.shiftKey == true && e.keyCode == 67 ||
// Ctrl + Shift + I (Chrome, Firefox, Safari, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 73 ||
// Ctrl + Shift + J (Chrome, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 74 ||
// Ctrl + Shift + C (Chrome, Edge)
e.ctrlKey == true && e.shiftKey == true && e.keyCode == 67 ||
// F12 (Chome, Firefox, Edge)
e.keyCode == 123 ||
// CMD + Alt + U, Ctrl + U (View source: Chrome, Firefox, Safari, Edge)
e.metaKey == true && e.altKey == true && e.keyCode == 85 ||
e.ctrlKey == true && e.keyCode == 85
){
devToolsOpened(e);
}
});
</script>
Keyboard shortcuts to open Developer Tools:
Chrome: https://developers.google.com/web/tools/chrome-devtools/shortcuts
Firefox: https://developer.mozilla.org/hu/docs/Tools
Safari: https://developer.apple.com/library/archive/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/KeyboardShortcuts/KeyboardShortcuts.html
Edge: https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/shortcuts
Timing solution (works for docked and undocked)
It is a bit intrusive but not as much as the debugger trap
var opened = false;
var lastTime = Date.now();
const interval = 50;
const threshold = 30;
setInterval(() => {
let delta = Date.now() - lastTime;
if (delta > interval + threshold) {
document.title = "P3nis";
opened = true;
}
lastTime = Date.now();
if (!opened) {
debugger;
}
}, interval)
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:
let workerUrl = 'data:application/javascript;base64,' + btoa(`
self.addEventListener('message', (e) => {
if(e.data==='hello'){
self.postMessage('hello');
}
debugger;
self.postMessage('');
});
`);
function checkIfDebuggerEnabled() {
return new Promise((resolve) => {
let fulfilled = false;
let worker = new Worker(workerUrl);
worker.onmessage = (e) => {
let data = e.data;
if (data === 'hello') {
setTimeout(() => {
if (!fulfilled) {
resolve(true);
worker.terminate();
}
}, 1);
} else {
fulfilled = true;
resolve(false);
worker.terminate();
}
};
worker.postMessage('hello');
});
}
checkIfDebuggerEnabled().then((result) => {
if (result) {
alert('browser DevTools is open');
}else{
alert('browser DevTools is not open, unless you have deactivated breakpoints');
}
});
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 change workerUrl to that resource.
Best way to have Debug-Mode on/off feature is to set a flag 'debugMode'='off' in localStorage by default -
localStorage.setItem('debugMode', 'off');
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' -
if(localStorage.getItem('debugMode') === 'on'){
//do something 1
}else {
//do something 2
}
i have a strange problem only in Chrome using an iframe but working in all others common browser.
the problem: If i type in the IFRAME and then press the button to send, it work fine, the focus back to the IFRAME and the cursor BLINK.
But if i type and then press ENTER to invoke the event handler function, the focus back but the cursor disappear. And then if you go in another window and then back the cursor appear. This happen only in Chrome. I did the example page to show the problem in action. Click the link below to see.
UPDATE: I added the code also here below
var editorFrame = 'myEditor'
function addFrame() {
var newFrame = new Element('iframe', {
width: '520',
height: '100',
id: editorFrame,
name: editorFrame,
src: 'blank.asp',
class: 'myClass'
});
$('myArea').appendChild(newFrame);
window.iframeLoaded = function() {
// this is call-back from the iframe to be sure that is loaded, so can safety attach the event handler
var iframeDoc, UNDEF = "undefined";
if (typeof newFrame.contentDocument != UNDEF) {
iframeDoc = newFrame.contentDocument;
} else if (typeof newFrame.contentWindow != UNDEF) {
iframeDoc = newFrame.contentWindow.document;
}
if (typeof iframeDoc.addEventListener != UNDEF) {
iframeDoc.addEventListener('keydown', keyHandler, false);
} else if (typeof iframeDoc.attachEvent != UNDEF) {
iframeDoc.attachEvent('onkeydown', keyHandler);
}
};
}
function resetContent()
{
var myIFrame = $(editorFrame);
if (myIFrame) myIFrame.contentWindow.document.body.innerHTML='';
}
function setEditFocus()
{
var iFrame = document.frames ? document.frames[editorFrame] : $(editorFrame);
var ifWin = iFrame .contentWindow || iFrame;
ifWin.focus();
}
function send()
{
resetContent();
setEditFocus();
}
function keyHandler (evt) {
var myKey=(evt.which || evt.charCode || evt.keyCode)
if (myKey==13) {
if (!evt) var evt = window.event;
evt.returnValue = false;
if (Prototype.Browser.IE) evt.keyCode = 0;
evt.cancelBubble = true;
if (evt.stopPropagation) evt.stopPropagation();
if (evt.preventDefault) evt.preventDefault();
send();
}
}
In the HTML page
<body onload="addFrame()">
<div id="myArea"></div>
<input id="myButton" type="button" value="click me to send [case 1]" onclick="send()">
To make more easy to understand the problem i've create a specific page to reproduce the problem with full example and source included.
You can view here by using Google Chrome:
example of the problem
I really need your help because i tried to solve this problem for many days with no luck. And all the suggestions, tips and workaround are well accepted.
Thanks in advance.
I'm not really sure what the cause of the issue is, as there are times where Chrome will give focus to the element correctly, though most of the time it does not. You shouldn't need to request focus at all, since the focus is not lost when you press the key. If you omit the setEditFocus() call, you should notice that it still works correctly in everything but Chrome, which apparently gets offended that you've removed all of the content in the body.
When you set contenteditable, every browser sets the innerHTML of the iframe document's body element to be something different:
Browser | innerHTML
-----------------------------
Internet Explorer | ''
Opera | '<br>\n'
Firefox | '<br>'
Chrome/Safari | '\n'
If you're not expecting to see that extra stuff when you parse the content later, you might want to remove it upfront in addFrame().
I was able to "fix" the problem by doing the following:
First, update the event handler so we can return false in it and prevent Opera from generating HTML for fun when we call getSelection() later...
function addFrame() {
...
window.iframeloaded = function() {
...
if (typeof iframeDoc.addEventListener != UNDEF) {
iframeDoc.addEventListener('keypress', keyHandler, false);
} else if (typeof iframeDoc.attachEvent != UNDEF) {
iframeDoc.attachEvent('onkeypress', keyHandler);
}
}
}
Edit: Removed original function in favour of the new one included below
Finally, return false from the key press handler to fix the Opera issue mentioned above.
function keyHandler (evt) {
var myKey=(evt.which || evt.charCode || evt.keyCode)
if (myKey==13) {
...
return false;
}
}
I had originally done what syockit suggested, but I found it was doing weird things with the caret size in Chrome, which this method seems to avoid (although Firefox is still a bit off...). If you don't care about that, setting the innerHTML to be non-blank is likely an easier solution.
Also note that you should be using className instead of class in the object you pass to new Element(), since IE seems to consider it a reserved word and says that it's a syntax error.
Edit: After playing around with it, the following function seems to work reliably in IE8/Firefox/Chrome/Safari/Opera for your more advanced test case. Unfortunately, I did have to include Prototype's browser detection to account for Opera, since while everything looks the same as far as the JavaScript is concerned, the actual behaviour requires different code that conflicts with the other browsers, and I wasn't able to find a better way to differentiate between them.
Here's the new function, which focuses on the editable content of the iframe, and makes sure that if there is already content in there, that the caret is moved to the end of that content:
function focusEditableFrame(frame) {
if (!frame)
return;
if (frame.contentWindow)
frame = frame.contentWindow;
if (!Prototype.Browser.Opera) {
frame.focus();
if (frame.getSelection) {
if (frame.document.body.innerHTML == '')
frame.getSelection().extend(frame.document.body, 0);
else
frame.getSelection().collapseToEnd();
} else if (frame.document.body.createTextRange) {
var range = frame.document.body.createTextRange();
range.moveEnd('character', frame.document.body.innerHTML.length);
range.collapse(false);
range.select();
}
} else {
frame.document.body.blur();
frame.document.body.focus();
}
}
Updated setEditFocus() (Not really necessary now, but since you already have it):
function setEditFocus()
{
focusEditableFrame($(editorFrame));
}
You know how I solved this one? In resetContent(), replace '' with ' ':
if (myIFrame) myIFrame.contentWindow.document.body.innerHTML=' ';
If it works, good. Don't ask why though, it might be one of those Webkit glitches with Range object, file a bug if you will.
Just quickly, can you try adding semicolons to the end of the lines inside your send() function? And see if that works.
function send() {
resetContent();
setEditFocus();
}