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.
Related
I'm logging JS client errors using Sentry and there's a lot of "TypeError: Load failed" errors. It's only occurring on iOS. I can't find anything on Google. Is this a native Javascript error or something else? What does it mean? This is separate from a seemingly related issue with "TypeError: cancelled".
Screenshot from Sentry of the breadcrumbs
From what I understand, the fetch API may deliberately return very limited error details on failure. (Otherwise, a malicious JS program could issue a variety of fetch requests and look at their results to identify which internal servers exist, which servers the user has access to, etc.)
If you have access to a Mac, you can see this for yourself by experimenting with fetch requests from the Safari DevTools console. For example:
The request for google.com fails due to CORS. The request for example.does-not-exist is an invalid name. The DevTools console gives full details, so a developer who's actually at the browser can troubleshoot, but those details aren't available to JS code; the JS code gets the same "TypeError: Load failed" message in each case.
If you're lucky enough to have a way to access the browser console, you can see more details, but otherwise, I'm not aware of anything you can do to track down the problem - it could presumably be virtually any network error.
Had the same problem, problems occured because of certificate and iphone took addres api as dangerous.
Helped me get into address api directly in safari or chrome for instance: https://my-adres-api/api/product and then choosing allow to connect with that address.
Now requests works excellent
In my case, this issue appeared mostly on iOS 15 in Safari. By debugging an iPhone through Mac I found that preload links with imagesrcset are not handled well in Safari (unless de-prioritized), throwing <link rel=preload> has an invalid imagesrcset value, as described in this question.
The reason why it looks like fetch error in Sentry is that preload link actually uses fetch under the hood.
Given it's just the image preload that is failing, and unless it's causing you performance problems, you can safely ignore this particular issue in Sentry until this webkit Bug 231150 - Safari complains about invalid imagesrcset value in where Chrome doesn't gets fixed.
When I visit my own WordPress based website sometimes I am seeing the following error message in Chrome console panel.
Failed to load resource: net::ERR_CONNECTION_CLOSED
Screenshot
As a result the main CSS file is not loading and the website looks messy. Still I can not find the reason but currently I have a very slow internet connection.
However, I want to know whether this is happening for my website visitors as well.
My question is, is there any solution to log this error message displayed in Chrome console panel using Google Analytics or any other error logging tool so that I can analyse how many visitors are seeing the same error?
Thank you.
There are a lot of tools to monitor servers status.
but to install them you need SSH access to your host server - this access is depend on your web-hosting company...
without any more details about your hosting plan i can guess that if you have low and cheap hosting plan - 1 shared CPU and 1 giga RAM - it not good enough for wordpress because wordpress need some moer resources.... and your visitors also see this error somtime - just like you...
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.
In a Chrome Extension, I'm trying to get gmail compose body content.
An error jumps out sporadically, and does not prevents it from working.
This is being run as a content script. I believe permissions are not the issue here, because when there is a permission missing, the error is different and the operation is blocked by Chrome, definitely not the case.
Error comes out in this line:
encodeURIComponent($canvas.find('iframe').contents().find('body').text());
where
var $canvas = $('#canvas_frame').contents();
Any information on this error and a possible turnaround?
You can not read cross site content using javascript. XSS Auditor of Google Chorme will never allow this.
Please have a look at http://en.wikipedia.org/wiki/Same_origin_policy
UPDATE 1 -
There is support for cross site communication using window.postMessage() in Chrome 2+. Please have a look at this documentation https://developer.mozilla.org/en-US/docs/DOM/window.postMessage
To give a good answer, we need more information:
where exactly you are running this code, is it in the web page, the extension's content script or the etension's background script?
Also, what does your manifest.json file look like? Which sites have you asked for permission to run on.
I suspect this is a case of a badly-written error message and really it is saying: your extension does not have permission to run on apis.google.com. In that case, simply add permissions for apis.google.com. More details are in the Chrome extensions docs: http://developer.chrome.com/extensions/manifest.html#permissions
I have an HTML5 page loaded on server along with a geolocation script. The code is working and has no errors. It shows the position and map the user. Right now, it's working well for everyone else and i also tried the same on other PC and it works. But, when i visit the page on my Chrome browser, nothing shows up. Why is that happening? Why can't it locate me and map me? I have Windows 7 OS running the latest Chrome and using data-card for internet.
This is the LINK
On the other hand, the Google page accurately shows my location on the left bar side
That page detects my location correctly in Chrome 17 (dev channel). I do see a JavaScript error, however: "Uncaught ReferenceError: geocoder is not defined" on line 81 of myLoc.js. Taking a quick look at the code, it doesn't appear to be defined anywhere. Have you perhaps forgotten to include a file?
I experienced the same issue with geolocation script. It seems to be an issue with Chrome specifically blocking the uri starting with "file:///" for security reasons.
See related articles:
http://groups.google.com/a/googleproductforums.com/forum/#!category-topic/chrome/give-feature-feedback-and-suggestions/E0yx7wne-RI
http://groups.google.com/a/googleproductforums.com/forum/#!category-topic/chrome/report-a-problem-and-get-troubleshooting-help/pNcftbZTN1E
HTML 5 Geo Location Prompt in Chrome
Check in your chrome, in settings -> advanced -> privacy (content) -> localization if you allow web pages to check your location (this menus can be named a bit different, I'm checking on Polish Chrome).
You say nothing shows up and the question to allow web page to check location should show up (this happens by me).
Another thing, geolocation is checked by Wi-Fi if available, determine it by your IP may be quite inaccurate.