I'm using Facebook Connect in my app. I have it working pretty well, but in the Safari Error console, I'm seeing errors like this:
Unsafe JavaScript attempt to access frame with URL http://...#... from frame with URL http://www.connect.facebook.com/extern/login_status.phpapi_key=..&extern=2&channel=http...xd_receiver.htm.
Domains, protocols and ports must match.
The app seems to function ok, though we are seeing periodic hangs and other bad behavior from Safari. When I run other Facebook Connect apps, I sometimes see this error too, so I don't think this is a problem with our implementation. Is it safe to ignore this warning?
Safari's cross frame security is tighter than other browsers, I have done specific try/catch wrappers to handle these cases, if it otherwise works, great.
Either way, would post the bug upstream as olliej suggests.
It means you're attempting some form of cross origin access, which is unsafe -- while it may seem benign it's probably worth trying to find out why you're hitting it, if you use the nightlies or the Safari4 beta you can use the debugger in the web inspector, and make it break on all exceptions, which will let you see when it's actually attempting the cross-origin access.
As for the hangs, if you can find some kind of reduced testcase it would be great if you could file them at http://bugs.webkit.org
This is a red herring. The request still goes through and everything is working properly but WebKit still logs an exception.
Related
On Chrome and Firefox I sometimes get the following error err_spdy_protocol_error
once I call the following website https://checkideas.com/.
I have researched on this topic on the internet and on this platform as well. I also found a working solution. Once I delete all the cookies and reload the webpage the error does not emerge.
So if you click on the website for the 1st time it will definitely work. But once there are number of cookies given the website cannot always be called. This is only the pattern I have identified so far. However I would like to have a sustainable solution.
What do I have to do to avoid this issue so that this issue does not occur? What is the source of the error?
Unfortunately following responses on similar questions did not answer my question:
Console errors. Failed to load resource: net::ERR_INSECURE_RESPONSE
What mean ERR_SPDY_PROTOCOL_ERROR in nginx?
I also cannot identify any issue with the certificate.
This error is related to the SPDY Protocol or an antivirus setting.
Updating to a later version of the browser should help fix the error (Google Chrome and Mozilla have dropped support for the SPDY Protocol.
This article contains methods that should help you fix the ERR_SPDY_PROTOCOL_ERROR
on Google Chrome or Mozilla.
I am experiencing a problem on the mobile version of my site where I get a HTTP 302 Found message in Firebug on Firefox, but the message is in red. I am spoofing Firefox to switch the User Agent string to mimic an iPhone, this lets me debug the mobile site on a desktop.
The problem is I cannot understand why I would get a blank response for my request, particularly when I don't get any errors in the Apache error log.
Where should I be focusing my attention on for this problem? I don't have this issue on the desktop site, which shares back-end functionality - it only occurs on mobile.
I'm also getting no JavaScript errors in the console.
The status code 302 means that the browser should open a different URL. Take a look at the headers, then you see the URL next to "Location:". Maybe there is something wrong with that URL.
The reason this does not happen with the desktop version could be that there is either no need to redirect (only the mobile site is at a different URL) or only the redirect for the mobile version is wrong.
I believe this error/warning is caused by a mixture of crossing protocols (HTTP->HTTPS) and also that the Firebug plugin for Firefox displays this scenario in red (making you believe an error has occurred).
My investigations have led me to believe that using JSONP, instead of JSON, when crossing protocols in this fashion will help.
I am using valums ajax-upload together with a ashx handler to let users upload files in the webapp Im developing. All is working absolutely fine for about 95% (around 3000) of the users.
For the last about 5% I get reports that the upload never finish, the wheel just keeps spinning people say. It seems that those who get this error are all are using IE9.0.
I have tested on all the IE9.0 I can come across but still have not been able to reproduce the error. I also have tried to log all thinkable errors but still no luck.
Please, can anyone reproduce the problem and hopefully give me a JavaScript console error transcript if any. To test go to step 2 (Upload section) and try to upload a small text file:
https://jobmatchprofile.com/backend/login.aspx?auto_login=24G3FY
UPDATE
I have been in contact with a user who experienced this problem. The error message can be seen here. It is in danish and says: "SCRIPT5 Access denied".
Error message
What is strange is that the user had same IE version as is working for others (me for example): I have been testing on: 9.0.8112.16421 and also ran WIN7 (as I). The Product-id differs however and he had a danish version where I have the US version.
UPDATE II
I was finally able to reproduce this error. I know this sounds a little strange, but belive me it is true: when opening the page via a link sent to my gmail account I get the same error. The user from first Update also used gmail to open the page.
Your reference to Gmail, specifically, points in the direction of a solution: Gmail strips the referrer data from the HTTP headers when you click on a link within an e-mail, except when you use your right mouse button and select "Open in New Tab [or Window]", presumably because this prevents their code from intercepting the headers. Is your script checking for a valid HTTP REFERRER, by any chance?
Are you making any cross-(sub)domain or cross-protocol AJAX calls? If so, then you may have to proxy the request(s). Consider the following solutions from the Yahoo! Developer Network:
http://developer.yahoo.com/javascript/howto-proxy.html
See also:
SCRIPT5: Access is denied in IE9 on xmlhttprequest
Access denied to jQuery script on IE
"Access is denied" JavaScript error when trying to access the document object of a programmatically-created <iframe> (IE-only)
(Un)fortunately, I wasn't able to reproduce the error in IE9, v. 9.0.8112.16421 (although I did get a general on-site error when trying to upload an empty .txt file, but this seems wholly unrelated).
The solution for ie9 is simply to upload using https:
https://www.parse.com/questions/internet-explorer-and-the-javascript-sdk
Even though you are sure that it's related to the user clicking the anchor within the email I would say it's because of policy settings within Internet Explorer. I have seen errors like these before and noticed that the most common errors were related to Internet Explorer policies of users within a corporate environment.
I am getting cross-domain request errors in chrome, when I try to perform a hit test with EaselJS (which uses getImageData()).
Unable to get image data from canvas because the canvas has been
tainted by cross-origin data.
The weird thing is that I'm running a local server and all images are served from this localhost:3000 and render nicely.
How do I use Chrome's Dev Tools to figure out the issue? All my images, html and JS are grouped under :3000/ in the Resources tab. What's the next thing you would check?
There might be something else in your code setting it off. Pour over everything for other examples.
Alternatively, install Firefox and put on Strict errors/warnings. I use Chrome as my main browser but sometimes FF has much more verbose errors/warnings that can make debugging a complex issue easier.
Also for the record, if you launch Chrome with the flag --allow-file-access-from-files it won't throw any of these exceptions.
As most production environments we have setup something to send us a notification if there is an error in our web application. The problem is ofcourse that this only covers errors on the server side.
My question to the community is: What are you doing about client side errors, especially in javascript?
And what about other quality of service issues, such as slow processing and other things that might be due to the client machine?
You can handle client side JavaScript errors with window.onerror event
Inside the handler make an Ajax request to your server side error miner and log the error.
http://www.javascriptkit.com/javatutors/error.shtml
Hovewer window.onerror is not supported in all browsers, jQuery can fill up the gap with its own event handler: a combination of window.onerror and jQuery(window).error should suffice
There's not a great deal you can do about JavaScript errors at the client end. You can trap window.onerror and use it to AJAX a report back, but:
(a) it's not supported in WebKit or Opera. To catch all errors you would have to wrap every direct-execution, event and timeout entry point in a try { ... }, which is very messy and gives you even less information than the onerror handler.
(b) you will likely be swamped with error reports you can't do anything about, with little debugging possible due to lack of information. You might be able to get away with it on an application that is only accessed by customers you know, but on a public-access site, a lot of errors will be spurious. Stuff caused by factors like:
connections to sites hosting scripts or AJAX failing or being blocked by firewalls;
unexpected security settings (browsers have options to block many interfaces arbitrarily);
broken browser add-ons, GreaseMonkey-like scripts, filtering proxies and bogus “Internet Security” tools messing with your code;
unsupported agents that behave oddly, like mobile browsers (especially the appalling IEMobile) and, if they have access, automated-browser bots;
many errors caused by third-party content like adverts, if you have any.
Again, for a limited-use application where you can directly contact any user who is experiencing problems, it might be of use, but for a site used by the general public it's a non-starter.
It's best to use ‘progressive enhancement’ to ensure that your application still works when JavaScript fails.