Automatically update websocket frame in chrome web inspector - google-chrome

When I inspect a web socket in Google Chrome Web Inspector, (see Chrome Web Inspector Web Socket Debugging), I have to keep clicking the socket on the left to refresh the messages on the right.
Is there any way to have this automatically refreshed each time a new message is sent/received? Or has this simply not been developed yet?

Unfortunately this is still the case even in dev channel (v27 atm) and looking at Chromium bugtracker it doesn't seem to be planned either.
Relevant issue here
You can vote on it, though I cannot say if that actually accomplishes anything.

I have tested with latest Chrome (32.0.1700), they still don't support automatically update of WebSocket frames. However you can use Fiddler (with FiddlerScript) to inspect WebSocket traffic in the same way you inspect HTTP traffic, and it supports auto refresh of frames.
Please refer to the article on CodeProject, which show you how to Debug/Inspect WebSocket traffic with Fiddler (with FiddlerScript). http://www.codeproject.com/Articles/718660/Debug-Inspect-WebSocket-traffic-with-Fiddler

Related

view-source in href shows error in console

Click Me
This used to work as a valid href attribute but it seems in the past few months it now shows an error in the console (I'm using Chrome):
Not allowed to load local resource: view-source: http://stackoverflow.com
I found some links from 2013 where this was once a bug in Chrome but said it was fixed.
Could someone point me to an authoritative source that can explain why this no longer works? I assume that this is security by the browser and not an angular issue (since view-source is whitelisted and used to work)
Looks like Chrome and Firefox (at least) disabled this within the past year or so
I found this thread, and these release notes explaining why and provides a timeline as to when the change took place.
Related StackOverflow question: File URL "Not allowed to load local resource" in the Internet Browser
Chrome responds with the "Not allowed to load local resource:" as a security protocol. I'm not sure why this used to work, but not now, though there is no real way around this unless web-security is disabled. There may be a different outcome on other browsers, but ultimately you are correct in thinking that it's Chrome's security.
The reason is that Chrome tries to preload URLs in background, to speed up your browsing experience.
If you open the DevTools after loading the page, the content of the items listed on the Resources tab may not be populated. This is also true of network requests on the Network tab. To see the fully populated resources on the Resources tab, first open the DevTools, then refresh the page, or navigate to the desired page with the DevTools open. Now select the html resource and it should be populated.

Nginx Server Caching in Chrome

I'm setting up a local development server on my Mac using nginx in place of Apache. I'm basically there, but having one issue.
I have multiple web apps, and each are set up using sites-available and sites-enabled - no issues here. The issue is that my browser of choice is chrome, and there's some weird caching going on that is causing the first-visited app to load each time. For example, I have:
site1.dev
site2.dev
If I load site1.dev, it loads without issue. If I load site2.dev, it's automatically redirected to site1.dev. I see this as a caching issue because if I use chrome's Incognito mode, I don't have the same issues (nor do I have them in Firefox).
Does anyone know what could be going on here? Or what the solution could be? Thanks in advance!
The solution is to open Chrome's Dev tools (right click, inspect element), click the network tab, and disable caching. Reload the first url, and try the second url. If there is no redirect, disable caching, and the issue is resolved.
Chrome only redirects from cache if the page was initially loaded with caching enabled.

IT Hit WebDAV AJAX Library on Chrome becomes unresponsive

I am experiencing an issue with opening a Microsoft Office Document, using IT Hit WebDAV AJAX library, in latest Chrome 39.0. running on Windows OS. It is a sporadic issue that occurs only in Chrome, and it happens when one opens a document multiple times. Word instance won't start, the page freezes and browser becomes unresponsive, and Chrome suggests killing the page. The only solution is restarting the browser, which solves the issue.
I have tried opening a document in Chrome on Mac OS X, and it is working fine. So are Mozilla and Safari on all operating systems. It seems to be a Chrome + Windows issue only.
Has anyone experienced this issue and is there a fix?
The Microsoft Office plug-in that opens the document displays a warning popup "Some files can harm your computer.", which is a modeless dialog:
If you quickly click on a link that opens the document more than one time the dialog will hide behind the main web browser window. As a result the web browser window is blocked.
You need to switch to that dialog and confirm or reject document opening, otherwise after some time Chrome will ask you if to kill the page or wait.
Note that there is no way to avoid that dialog, this is a built-in MS Office functionality as far as I know.
Chrome will only work good with ITHitWebDAV if the user has got Office 2013 or superior.
Google is blocking all Java applets and NPAPIs now, so good luck with that. I just detect the browser of the user that wants to edit a document, and if it's chrome, I warn him to change to another browser like Firefox with a modal, and that's all.
Very poor support between Chrome and ITHitWebDAV, and no much you can do about it.

Does Google Chrome Frame break IE8 console output?

This is a question about debugging a project, not about writing the code.
I am on the final stages of developing an HTML5 web app. Fairly last minute, our client tells us it should run on IE8. Since I use the HTML5-canvas in the app, this required the addition of Google Chrome Frame. Once installed and testing, however, IE8's developer console no longer prints any data, and the HTML viewer never loads. Is this a bug? Is there a way to fix it? It will really suck if I need to debug with alerts...
From Google Chrome Frame documentation:
You can use the Web Inspector in GCF just as you would in the Google Chrome browser. To use it, right-click and choose "Inspect Element". Logging is available via the console.log method, and you can set breakpoints and inspect network activity.

How can you tell exactly what insecure items are causing a browser to warn about mixed secure and insecure items?

In Firefox, I view my site and get no warnings about insecure mixed content.
Using FireBug, I can see that every request is https.
In Chrome, I get the https crossed out in the address bar.
I viewed source in Chrome and then ran this regex /http(?!s)/ but the only things it found were the href attributes for some external links and the doc type and http-equiv meta tags.
Using Chrome's Resource Tracking revealed all requests were https too.
This includes Google Analytics, jQuery from Google's CDN and Facebook like scripts.
Is there any specific tool I can use to show non https requests, or anything further I can try?
I found that I get the "mixed content"-warning in Chrome even when there is no mixed content, if sometime during the session mixed content was already encountered on the domain.
(Also mentioned here: Why is Chrome reporting a secure / non secure warning when no other browsers aren't?)
In Chrome's Developer Tools, the Console tab shows the resources that it won't load because they unsecure.
You can add the "scheme" column to the Chrome developer tools network tab to show which requests were sent over http or https:
Press F12 to show the developer tools
Switch to the Network tab
Right click in the column headers and select "Scheme"
Reload the page to show which elements are loaded over http or https
In situations like this where it's helpful to see exactly which protocol is being used to load resources, I would recommend Fiddler2 as a browser-agnostic solution that can show you exactly what traffic is occurring on each request.
From the site:
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.
Edit: In-browser debugging tools are becoming really good so this third-party tool may not be as useful as it was when this answer was first written.
Open up the Web Inspector and find the yellow triangle (warning) in the top right. Click on it and it will display all security issues.
In 48-th version of chrome they added a security panel. Using it you can quickly identify the mixed content resources:
Do you have the HttpFox plugin for FireFox? That'd work, I think.
Among other things, it reports on the URL, Method, Result Code, and bytes of all the assets that a web page requests. It's what I've used to trap the occasional non-HTTPS graphic, etc. I'm sure the other suggested tools would do the same...
You can use SslCheck
It's a free online tool that crawls a website recursively (following all internal links) and scans for nonsecure includes - images, scripts and CSS.
(disclaimer: I'm one of the developers)
I know this post is old, but I ran across it and had the same issue. I clicked on the Chrome menu (top right corner), scrolled down to Tools> and selected Developer Tools. Clicked on the Console tab and it told me exactly what the problem was... the favicon was served over http, not https, but of course it was not in the page source code. Corrected the problem in my CMS, which loads the favicon without code in the page... and no more error!
Note that 'mixed content' and 'mixed scripting' are detected seperatly. Check this site for the meaning of the icons in Chrome: https://support.google.com/chromebook/answer/95617?p=ui_security_indicator&rd=1 (click 'see details' link).
Grey icon = mixed content, red icon = mixed scripting.