It being a top-level menu item is just convenient for developers. You don’t have to open the developer tools, click the inspect button, and then find the item on the squished version of the page. You can just right click on the item when you’re viewing it normally, and choose inspect.
There are far more useless items on that rightclick menu that you could get rid of before Inspect. You don’t need “Back, Forward, Reload” since they are in the toolbar. Save As, Print, and Cast are all in teh … menu. Most of your extensions don’t need to have menu options available by default.
What is really needed is a way to customize the right click menu and remove stuff we don’t need. Instead of Chrome’s recent new decision to add more whitespace and make it even longer.
I was working in the mid 2000s for a small online casino start-up. The owners were two brothers. One was CEO and the other the CFO.
Now, in online gambling there is rampant copy/paste theft of content, terms and conditions, etc, because it is easy and cheaper than paying a copywriter or a lawyer. So the CFO asked me to disable right click altogether, which is possible with javascript. So I did, although I told him it was futile and would not work against any junior developer. Anyway I did it.
The next day, he calls me in, and tells me that he, in fact, uses the right click menu for “forward” and “back” and can I disable everything except those?
So I did what I hope any young developer would do: screenshot the right click menu. Photoshop it to make it look like all other options were disabled. Write javascript to hide it, but follow the mouse. Make it appear on right click. Used javascript to allow the forward and back parts of the image to perfom the same functions.
Then I limited it to Internet Explorer, because I used Firefox and he didn’t. I don’t think he ever found out.
We use inspect to emulate mobile devices, without having to have the particular phones. It’s better now, but a few years ago, there would be huge differences in how certain elearning packages would behave depending on whether the user had an iPhone or Android.
how would that work? Say, I delete the overlay in the inspected code … but wouldn’t you have to update the code in the browser (F5) … which would load the orig. code from the webpage’s server, again?
Yes. The inspector, like the other devtools, is live. It shows exactly what is on the page at that moment, and any change you make affects the page itself. That’s what makes it so useful for development.
It’s not like view source, which is just a static copy of the main file that loads the page.
You don’t reload the page. You’ve already loaded the page and deleted the junk that was blocking your view, so now you can read it. If you reload, the junk you deleted will be there again.
In addition to putting an overlay in front of the content, the page will probably also have disabled scrolling. You can defeat that by adding style=“overload: auto” to a high level element such as the body tag, or sometimes by deleting a class from the element.
A few sites are smart enough to not even load the content if you are blocking ads — this trick won’t work with those.
Another guy who relies heavily on this feature for troubleshooting.
If we are dealing with a business critical system in Germany that is running super slow, our network analysis tools can’t see inside the traffic because it is encrypted, but we can ask the user to demonstrate the problem on a Teams call and open the Developer Tools so we can see which stream is the one of interest.
We can then use this information to correlate with the network traffic and determine if it was the browser’s fault, the app server’s fault, or the database’s fault.
Another cool thing we can do that is much more geeky is to have the user generate a key file with SSL keys while they run the application. This can be done easily in Chrome. We can then use their key file in Wireshark to decrypt the traffic between their laptop and the app server.
I don’t think the Developer Tools should be in a prominent menu though.
Can someone tell me why car hoods open? People have no idea what goes on in that engine thing so why do all cars have a hood that opens to look at the engine?
I’m not sure that’s a fair analogy. More fair (to me) would be: I can’t “inspect” any other bits of code on my computer, so why can I see (at least some) of the code used on a webpage? Why isn’t this information obfuscated as it is everywhere else with code? I assume it has to do with some kind of old standards and how HTML is delivered to your computer and browser, but I don’t see why that couldn’t be obfuscated.
You can inspect any code on your computer, but most of it is compiled into machine code that is not easily interpreted in a simple examination, but you can conceivably disassemble it to see actual instructions by name instead of simply the binary code. Symbol information may be included with some compiled code providing the same level of examination as browser code. Although it’s rarer now, some interpretive languages run directly from the source code as HTML can. This was common in the days of interpreted version of BASIC, but compiled versions of the language were created for more efficient execution, and to hide proprietary code. Web browsers evolved to use HTML source code as a transportable standard language to create a platform independent environment. Many web pages, probably the vast majority of them use only a little HTML to start up a page which can easily integrate other types of code that can work with the browser’s own object system and make use of the underlying machine’s OS so more symbolic information is provided with the code that can be inspected. So much code now in and out of browsers has to integrate OS level object environments and client-server interconnectivity that requires more symbolic information to be available even when source code is not. Without a lot of inspection tools it would be extremely difficult to track down problems in such high integrated applications where most of the code executing comes from a variety of sources. A non-web based application usually doesn’t have an inspect button to click on, it’s just standard for browsers to have that.
You can use this tool to find out where you are in the queue when trying to buy concert tickets on Ticketmaster, to give one answer totally unrelated to development.
On my Chrome setup, you can also get there with control-shift-c. I know this because I use that key combination to copy (and the control-shift-v version to paste) with my terminal window, but have to use it without the shift key in Chrome. This hits me sometimes when I’m trying to copy commands in an e-mail or Google Meet message, pasting into my shell.
I actually didn’t realize that F12 not only opens the same interface, but lets me close it too. Control-shift-C doesn’t close it, and I’ve been using the mouse to get over to the x each time.
On Chrome, Ctrl+Shift+C (Mac: Command+Shift+C or Command+Option+C) opens the dev tools elements panel. It is the same panel that opens when you right click and select “Inspect (Q)” from the context menu.
On Firefox, the same key combination pulls up the equivalent developer tools inspector tab.
In Windows, when you are running remote control app, you need a way to distinguish between copying / pasting with or between the programs on your local screen, one of which is a remote control program, versus copying / pasting within the remote screen that you’re seeing the remote window.
It’s been a bunch of years since I did that stuff daily, but that sure sounds familiar. To cut and paste within the remote window use shift.
A very niche and specific use - when solving “mystery” or “puzzle” geocaches. I’m talking about those puzzles where the nature of the puzzle is not immediately apparent from anything visible on the page (in the extreme case, the “description” appears to be completely blank).
When you “View Source” you may occasionally find the co-ordinates or other vital information readable in plain text in a section of the html that is not displayed in the body of the web page. Or you may discover that what looks like a dot on an otherwise blank page (or hiding in the text) is actually a link or an image file.