Chrome Inspector Detector | Hacker News Reader

Chrome Inspector Detector

adamschwartz.co

176 pointsafschwartz86 comments

Detect whether the Chrome Inspector is open and docked, open and in a separate window, or closed.

This ushers in a new era of annoying and pointless "This website prevents right clicks" popups.

Just the other day I said to my coworker everybody, by now, knew how to use firebug/inspector (he disagreed and, being in support, he does see more suffering than I do) - we were looking at a client site that had a javascript obfuscation of the html source.

It's like this grand battle stage of the worlds tiniest violins.

A developer could use this to kill all the DOM nodes on the page when the console was opened. This might be the next generation of:

    img.onclick="javascript:function(){alert('Don\'t steal!');return false}"

Well ... people who know how to use the inspector also know how to get the content without using the inspector. Although it would be significantly more annoying.

but then we could just ensure that this line gets called first

  console.profile = console.profileEnd = function () {};

Not only that, you have to save a reference to the parts of the console that you want to use just in case they attempt to destroy those.

    var c = console
    var l = console.log
    var log = function(){ l.apply(c, arguments) }

Now they can't break the console from working with stuff like:

    console.log = function(){}

well in that case i guess you could always do

  var _console = console;
  console = undefined;

You may break something by breaking it yourself, like naive code: if (window.chrome) console.log("dev forgot to delete this"))

view-source would still work right. so

How do I press ⌘ on Linux?

Just updated with OS-specific instructions: https://github.com/adamschwartz/chrome-inspector-detector/co...

Works great, thanks!

Easy -- just plug in an apple keyboard and hit ⌘

But it is Ctrl + shift + I on windows and I thin Linux too.

It's becoming increasing clear that on HN you're a second class citizen if you don't use Chrome on a Mac and develop on RoR.

That's not contributing anything of value. Offer advice if you've got it, otherwise I don't think theres a valid need to be snarky.

Says 'Add Comment" not 'Add Advice'. Also the advice is clear, don't use OS specific keys for the web.

Since when I signed up, ~1500 days ago, it was like this. Except everyone used Safari because FF was extremely laggy on OS X.

That's not true. Python is also acceptable.

node is fine

I think you're confusing popularity with exclusion. Doesn't bother me or make me feel like an outsider because I use Opera as my primary browser and mostly Linux/Windows PCs. It's all a frame of mind and such statements are not really needed on HN because it's really not true.

I actually read the Rails articles quite a bit just because I like to not limit what I do or know to a small subset, even if I do not actively use it. Software does not come to other platforms unless one ports it, after all :)

Disclaimer: not a RoR developer, but I do use Python.

One of the main reasons I switched away from Opera was because so many neat little projects made with new HTML5 technologies would not work in Opera. This goes both for small side projects as well as business ventures.

I do understand the lack of support for Opera, with it having just a tiny market share in the US, but it still is a form of exclusion.

I'm glad Opera is switching to Webkit & V8 because besides the many websites breaking I found Opera to be much nicer to use than Chrome or Firefox.

Yeah, I'm kind of used to Opera not always working with everything that it does not phase me anymore after 10 years of use. If it's something I need to see Opera won't render, I either hack around it in Opera or just open Chromium. I also understand that Chrome is popular and many of the projects on hn are hacks put together for the developer and to show us what they do for fun and learning versus projects made for the masses, so I give leadway when things don't always work. Sometimes it's just a simple mistake and the developer is glad to fix it (like he did here [updated in the linked article] for anyone that did not have an Apple keyboard). Although we all have our favorites, most of us like to be accommodating if it does not require hours of additional personal time.

I have all the large browsers installed though for web development, so I can always open something else if needed. I just can't move away from Opera, because of all the native power features I would have to give up or find extensions that may or may not work exactly the same and have future support by their developers. I can say though that unlike some sites I frequented in the past (such as slashdot), I have never had anyone on HN make snarky remarks about me being an Opera user, which is refreshing and quite the opposite of being excluded.

I do think Webkit will help Opera in the long run as well, as long as they do not use it as a reason to throw away their long term commitment they have stuck with to keep backwards support for features and user interface elements. If they ditch most of that on the notion they can just tell users to use Chrome extensions, I would be truly sadden and have little reason to use Opera anymore. I'd probably end up forking Chromium in attempt to make it function like Opera once did and hope other former Opera users would help contribute via code commits along the way. That's just worst case thinking and I'm going to stay optimistic for now :)

Not to get too off track though from the discussion, but the OP (above my original reply) is correct in that there is quite a bit of RoR and Apple upvoted articles (if that was his point), but there are many others in a variety of topics. Perhaps not everyone is as interested as I am about broadening my knowledge of various technologies whether I use them or not, but I think many of us on HN are. Since I don't follow RoR or Apple news that much, I don't mind seeing it, because it at least keeps me exposed to information I don't follow actively on my own.

Also, there is no such thing as an X desktop that isn't a default install of Ubuntu.

DHH would certainly agree: http://david.heinemeierhansson.com/arc/000433.html

Another gem http://37signals.com/svn/posts/3084-watching-apple-win-the-w...

This is shit, to say the least. Oh wait, you might have meant second class citizen in terms of money? May be, I don't care in that case.

but php bashing is an habit here.

I was using chrome for many years, almost from the start. But switched to firefox a week ago, because my chrome started to feel more and more laggy, both on home and work computer. I'm not disappointed yet.

“⌘” is the key that the USB HID spec calls “GUI”. It is the same key as (for instance) “Meta” on Sun keyboards and the Windows logo on MS keyboards.

Now you know how to press it.

Your next problem is that much Linux software (Chrome included) insists on using the MS Windows convention of overloading Control for menu shortcuts. This is a great nuisance when you want to be able to use, for example, both Control-V (the conventional LNEXT character in *nix consoles) and GUI-V (the conventional Paste shortcut in GUIs).

Pre-Linux X programs tended to get this right, since they were not focussed on slavishly imitating MS Windows. Apple got it right somewhat accidentally — the original Mac keyboard had no Control key at all, and it got added to support familiar editing and remote terminal uses.

Oh, the evil things I could do with this to coworkers who try to debug my Javascript code. Oh, the evil things I could do...

It may not be clear, but the main use case for this app is not to harm someone, but to aid in development. Perhaps you're making a game and want to pause it or show wireframes when toggling the inspector. Or perhaps you're a designer and you want to show a grid layout whenever you're inspecting elements.

Or perhaps you want to make it so that when someone tries to inspect a DOM element, the element turns into a youtube video of Rick Astley singing "Never Gonna Give You Up." --Just sayin...

That may have been your aim and while there is a great potential good, there's also a great potential for evil. You've opened pandora's box and now we'll see how it plays out. My guess is that we're going to see a lot of misguided website abuse this until the Chrome team has to patch it so websites can't know its state.

Thanks for reporting all of the issues.

I'll continue to improve and update https://github.com/adamschwartz/chrome-inspector-detector/is... with the issues reported here. Thanks.

Could be an intriguing way to detect other developers visiting the site and communicate with them. Last time I checked, the front page of https://vimeo.com was using the inspector console as a recruiting tool.

Great idea!

It's a nice demo and congratulation to Adam but I wonder if I m the only one that doesn't like that the browser allows this detection. I mean accessing the log is one thing but shouldn't this be this unreachable fro; the sandbox?

Defeated:

    javascript:clearTimeout(setTimeout(function(){}, 1) - 1);

But what if he starts using setInterval? A more global solution is to: Open the "sources" panel, click on "Event Listener Breakpoints", then click "set Timer" and just delete the lines where it is calling the detector function.

    chrome.inspector.detector=function(){return{}};

and what if he stops putting a public reference to the "detector" method?, read previous answer again.

Use Firefox.

Doesn't work exclusively with the Chrome Inspector. Having the downloads bar at the bottom sets this off as well, for example.

Having a non-standard window zoom also sets this off.

Chromium / Ubuntu I only get it with greater than 100% zoom, zooming out doesn't trigger.

I've made the docked/undocked an experimental feature since it was causing the issues you were seeing. Please let me know if you're still seeing any issues with false positives for open.

From quickly checking the code before the reports, you seemed to be first checking for the height thing, and prematurely returning, before running any profiling. Wouldn't you avoid these problems if you first checked for the surer stuff, and then checked the height?

@goldfeld absolutely. However, the profiler check mucks up the console output so I was hoping to use it as a fallback. For now I've made it experimental and will keep it that way until we can resolve the issues you pointed out. (https://github.com/adamschwartz/chrome-inspector-detector/is...)

Thanks for the bug report. The downloads bar bug is fixed.

This is cool, I used the same technique in the discover-devtools.codeschool.com course for the first challenge.

Yup! We credited http://stackoverflow.com/a/15567735/131898 in the README (https://github.com/adamschwartz/chrome-inspector-detector/bl...) which in turn credits you. :)

Works fine to detect the inspection window, but a false positive (as "open and docked") if I change Chrome window state from maximised to normal.

On Windows, use F12 instead of Ctrl + Shift + I

I was hoping it is doing kind of this detection http://homakov.blogspot.com/2013/03/pwning-your-privacy-in-a...

you simply used chrome api :)

On Canary it continually spams this on the console:

  Profile 'Profile 13' started. chrome.inspector-detector.js:16
  Profile 'Profile 13' finished. chrome.inspector-detector.js:17
  Console was cleared

Apologies if this is a silly question, but why is console.clear() needed for this to work?

EDIT: Oh, I get it, it must be housekeeping to clear the log messages generated by the profiler.

Yup! :)

Worst case scenario, to defeat this: Save page to local drive, edit JS (and remove this) in your IDE/text editor. Open locally.

You'd have to open it with --disable-web-security to bypass potential CORS problems on some sites.

good point

defeat what? is there some attack shown?

Interesting, I thought that you played with the document and window height

    delete window.chrome.inspector

Did I win?

Doesn't work even without the downloads bar. ( Win 7 , Chrome Beta )

Also doesn't work on ubuntu (at least not with scrotwm)

Ubuntu 12.10 with Cinnamon works.

Can you provide any other information?

Instructions are incompatible with Chrome OS.

Great for easter eggs!

Cases uses for this?

$5 to the first Chrome extension that detects this and kills it.

I don't get it?

Perhaps you're making a javascript game and want to pause it or show wireframes when toggling the inspector. Things like that...

Good idea. You should package this as a Chrome extension then. No reason why I should run your code in my app, even in debug mode, when it can run outside and sandboxed.

False. http://i.imgur.com/7keR7aL.png (Ubuntu 13.04, Plasma/KDE, KWin, Chrome 27.0.1448.0 dev. It says that no matter what I do...)

I've made the docked/undocked an experimental feature since it was causing the issues you were seeing. Please let me know if you're still seeing any issues with false positives for open.

Looks okay now!

    console.profile = console.clear = function(){}

That's all you need write in the console to stop this annoyance.

Does that make profiling unusable?

It does, but you usually don't want to profile other dev's pages; here is another solution that doesn't make profiling unusable:

    chrome.inspector.detector = function(){ return {open:false}}

But a more aggresive solution is this one:

    console = undefined;
    var iframe =     document.body.appendChild(document.createElement("iframe"));
    iframe.style.display = "none";
    window._console = iframe.contentWindow.console

And you can use `_console` instead of `console`

It may not be clear, but the main use case for this app is not to harm someone, but to aid in development.

Perhaps you're making a game and want to pause it or show wireframes when toggling the inspector.

Or perhaps you're a designer and you want to show a grid layout whenever you're inspecting elements.

It doesn't matter what your intentions are; eventually it will be used to annoy some developers, lets just hope that it doesn't become something common.

It would be nice to have DOM events (just like onResize), which would only be activated when activating the related option in the console (just like the "Show XHR requests" option).

[edit] https://code.google.com/p/chromium/issues/detail?id=223418

Starred. Thanks for the submission. Would definitely be better to have this integrated into the browser.

It kind of gets in the way of development though when the profiler window gets clogged up with the probes... maybe the detector could clean up after itself?

We agree. We're actively looking into other ways to do the detection. For example, when the inspector is docked, we might not need to run the profiler check. We'll continue to update as we find better solutions.

Reply on news.ycombinator.com