We Keep Coding

Find HTTP Request Initiator Line In Internet Explorer Developer Tools

I'm getting some odd behavior when my page is loaded in Internet Explorer 11. When my page loads in IE 11 and I watch the Network Tab of the Developer Tools I see a HTTP Get request to the base URL of the page. By base URL I mean the URL without any parameters. This is causing a 500 Internal Server Error to get fired because the Action on the other side of the Request doesn't accept no Parameters. I use Elmah to send me a mail for any unhandled exceptions so whenever a user is using IE I get a ton of Error notifications. This is only happening in IE. Both Firefox and Chrome work as expected. Also, this doesn't seem to break the page in anyway. I only know about this error because of the Emails I'm getting. No User has reported an issue when using IE 11.
Short of searching through every line of Javascript code both 3rd party and my own is there a way in Internet Explorer Developer Tools or even another 3rd party tool that will tell me the exact line (or even js file) that initiated the Http Get Request similar to Chrome's Development Tools?
Here are some images showing the call I'm talking about. The blacked out portion is my API Key.
The original Url being called in the below examples is http://localhost:44301/Grower/Profile/28
The first image is of the Internet Explorer 11 Development Tools with the offending Http Get Request highlighted.
Next is a Fiddler Screenshot of the same request highlighted.
And finally the Chrome Developer Tools showing no such call happening.

I think there's no such a way in IE dev tools to find the initiator line of HTTP request.
But in my research, I find that we can get the file path of the HTTP request initialed using Fiddler. We can find the file path in Inspectors -> Raw -> Referer:
The file path in Referer in Fiddler is exactly the path in Initiator in Network tab in Chrome. So you could try to check the file path using Fiddler.

Google Embed Api Shows White Boxes Ubuntu 18.04

Tasked with a project integrating Google Analytics to charts via the Embed API. I cannot get the demo on the Google site to load, all it shows is white boxes, see attached "embed-api-demo.jpg:"
https://ga-dev-tools.appspot.com/embed-api/interactive-charts/
Similar questions on S.O. relate to developers not getting their code to work - this issue is loading the demo from the Google site.
My environment and tested in:
Ubuntu 18.04 (Unity)
FireFox 65.0 64 bit
Chrome (Chromium) 72.0.3626.96
No special filtering or blocking in the browsers and have conferred with colleagues on Mac and Windows, it loads fine for them. A second Ubuntu user on Mint/Gnome has confirmed, also white boxes.
If it turns out to be an issue with the O.S. I could probably install VirtualBox and struggle through with Windows, but would prefer not to do that (and guessing it should load regardless of platform.)
I have worked with G.A. and the embed API extensively but it has been a few years and a lot has changed, presume I'm starting from scratch.
The debug console reports different errors in FF vs. Chrome. I have not yet dug into a browser setting that may be interfering with loading the demo, that is my next step.
FireFox:
CSI/tbsd_ cb=gapi.loaded_0:620:127
CSI/_tbnd cb=gapi.loaded_0:620:127
Content Security Policy: Ignoring “'unsafe-inline'” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “https:” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “http:” within script-src: ‘strict-dynamic’ specified
Object { error: {…} }
cb=gapi.loaded_0:106:97
uncaught exception: [object Object]
Chrome (Chromium:) The "opened" error details are quite long but here is the version with the details closed. Saving the log doesn't show this information. see attached "chrome-error-console.jpg."
-> GET https://content.googleapis.com/analytics/v3/management/accountSummaries?max-results=0&_src=embed-api%3Av1 403 cb=gapi.loaded_0:149
-> {error: {..}} cb=gapi.loaded_0:106
-> Uncaught -> {error{...}} cb=gapi.loaded_0:76
-> [Deprecation] chrome.loadTimes() is deprecated, instead use standardized API: Paint Timing. https://www.chromestatus.com/features/5637885046816768. common.js:25
Thank you for any pointers/direction anyone can provide.
embed-api-demo.jpg
chrome-error-console.jpg

Marking solved. What is not clear from the demos is that they only display data linked to your account. You must be logged in to G.A. to see the demos.
This doesn't make a lot of sense to me at this point, if I am a site owner and want to show my visitor a graph of stats, they shouldn't need a G.A. account to see them.

Chrome blocking iframe requests as cross-origin request even when origins are the same

This one has me stumped.
I have a web app that has a file upload/download area. Files are downloaded in the background via a temporary iFrame element. This is a single-paged AJAX application and the UI is written in Javascript, jQuery and uses the jQuery.FileDownloader.js to manage the iFrame. The application runs over HTTPS and the site and download URL are on the same exact domain. The back-end is a RESTful application. This has worked great for months. Until today.
All of a sudden, when attempting to download a file in Chrome, the browser reports an error of "Blocked a frame with origin https://example.com from accessing a cross-origin frame."
The problem is that the origin of the main site and that of the iframe are the exact same domain. I have ensured that the domains are the same as well as the protocol. Chrome is the only browser that throws up the cross-origin error. IE, Firefox, Opera, Safari... all work as expected. It's only in Chrome and it's only as of today. To make things worse, no updates were made to the browser. It truly is spontaneous. I've also ruled out plugins as the cause by running in Incognito mode, where none are allowed to run by my settings, as well as disabling my anti-virus software. This problem is being exhibited on other computers, in other locations (not on our LAN or subnet), all running Chrome.
And, again, both domains of the parent frame and the embedded iframe are identical. This only happens against the production server which runs over HTTPS. Other non-HTTPS sites (e.g. our dev environment, localhost) don't have the problem. Our SSL is valid. Since this is a single-paged AJAX application, we're trying to avoid popping up another window for the download.
Hopefully, someone can offer some advice. Thanks in advance.
Update: After additional research, I have found the solution to this problem is to enclose the filename in the response header in double-quotes.

I have found the cause of the problem. It turns out that Google Chrome has problems with files that have commas in their filename. When downloading the file via a direct link, Chrome will report that duplicate headers were reported from the server. This has been a long-standing problem with Chrome that has gone un-addressed. Other browsers are not susceptible to this problem. Still, it's a fairly easy problem to troubleshoot and, indeed, when I searched on this error, the first search result had the solution: remove commas from filenames when handling a request from Google Chrome.
However, this wasn't a direct link, it was an AJAX-request, which results in a different exception. In this case, the error provided by Chrome is the cross-origin request exception and this is what made it so difficult to troubleshoot.
So, the tl;dr of it all is to strip out commas in the names of uploaded files.

Another instance I found where this issue occurred is after executing code similar to:
document.domain = '[the exact same domain that the iframe originally had]'
Removing this line of code got rid of this error for me.

Does chrome fully support performance API for all resources entries?

Is this a bug in the latest version of chrome - 29.0.1547.76 m?
When you raise an xmlhttprequest, lets say while downloading an image, you can see that the resource is downloaded with status code 200 OK in network tab, but the performance.getEntries() or performance.getEntriesByName(resourceUrl) doesn't list the resource entry. When the page load is complete and you evaluate performance.getEntriesByName(resourceUrl) in console, it lists the image entry properly. So, there is a lag in chrome while populating the resource entries in performance object?
In IE10, this works perfectly fine.

Chrome plugin development: user:pass#url not supported by Google Chrome anymore?

I develop a Chrome plugin that uses XMLHttpRequest to send a GET HTTP request with an username/password to a basic-auth-protected URL, so that it can then "auto-login" to it afterwards (since Chrome caches credentials for HTTP basic-auth).
Here's the code I use:
var xml = new XMLHttpRequest();
xml.open('GET',<url>,false,<username>,<password>)
xml.send('');
It used to work fine for quite a while, but started failing some time ago. The plugin code hasn't changed, so I thought it could have to do with Chrome itself. I downloaded a previous version for OSX (17) and BAM, it worked again.
After some additional research, I found out that it might have to do with Chrome 19 not supporting the username:pwd#url syntax for authenticating to basic-auth protected URLs, because when I send the XMLHttpRequest, I see this in Google Chrome's js console:
GET http://user:pass#domain.com 401 (Unauthorized)
Does anyone know whether it's a bug or if Chrome stopped supporting this feature?
Thanks,
Marcelo.

You are not the only person having this issue. It's ruffled several other people's feathers.
However, given the comments from the Chromium Developers:
The support for embedded auth in URLs was intentionally deprecated.
It looks like it was removed intentionally.