I did the mistake of creating my entire web application and not testing it on IE along the way. I only tested it on Firefox and Safari. The web app runs fine on both Safari and Firefox but it gives a Permission Denied error on IE.
I am using Google AuthSub authentication and so for authenticating using Google Account, it first redirects to allow the app access to Google Account. After authentication, IE changes 'http' to 'https'. This does not happen with either Firefox or Safari. They remain with the 'http' protocol.
IE then gives a Permission Denied error. Is the JavaScript conflicting with 'https' in any way?
The app is here -> http://ankitahuja.com/apps/proxycal
and the error-causing page is -> http://ankitahuja.com/apps/proxycal/proxycal.php
When I open up the proxycal.php page in both IE and FF, an error is raised on this line in the Javascript (in function _run):
calendarService = new google.gdata.calendar.CalendarService('proxycal');
Here, calendar is not a member of google.gdata.
I suggest you debug through the call stack to find out what is not being initialized.
I've run into that error before in IE. Most often, it was because I was fetching data from another domain using XmlHttpRequest. Check the "allow data from other domains" setting in IE's Internet Options, make sure it's allowed and then see if you get the same error.
In IE you can use XDomainRequest, but not for https from http, which is blocked and This is an expected by-design behavior (though not expected in FF/Chrome)
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.
My react app works in every browser, But not working in Safari on MacOS(Catalina OS & Version 13.1.2 ). I get no error, no console message, nothing that would give me some idea. It only renders blank screen in Safari.
Some people suggest me to clear the cache or turn off the cache and then reload the page but that doesn’t work for me.
I tried to run my react app locally in safari and then I was getting these error messages in the console :-
[Error] Failed to load resource: A server with the specified hostname could not be found.
[Error] The source list for Content Security Policy directive 'script-src' contains an invalid source: ''strict-dynamic''. It will be ignored.
Do you have any idea how could I fix this issue?
Thanks
I found the issue. The main reason why it failed was 'callback' function that was not triggered in safari. So I checked on official website of google(https://developers.google.com/identity/sign-in/web/sign-in) about google sign-in and I got that we should use (meta name="google-signin-client_id" content="YOUR_CLIENT_ID.apps.googleusercontent.com") and it fixed the issue. Now it's working fine in every browser.
My draft website works in FireFox and IE and in Android Chrome but does not work in desktop Chrome. Desktop Chrome gives me this error
"Uncaught DOMException: Failed to execute 'send' on 'XMLHttpRequest'".
Website URL: http://beyondproxima.appspot.com
URL loaded in XmlHttpRequest: http://beyondproxima.appspot.com/data.json
Failing in Chrome version: 56.0.2924.87 (Win 7)
This error is usually a cross origin scripting issue but I am trying to load a JSON file (synchronously) from the same domain, port etc...
Is Chrome blocking my request because I am doing an old-fashioned and deprecated synchronous request?
In my chrome your url is working fine and data is getting loaded.
Warning Message is there in chrome
"Synchronous XMLHttpRequest on the main thread is deprecated because
of its detrimental effects to the end user's experience. For more
help, check https://xhr.spec.whatwg.org/."
I think its just a browser issue and nothing else.. Just update your chrome.
Chrome 56.0
avoid making synchronous requests.
Instead of this..
xmlHttp.open("GET", "http://google.com", false);
use true in place of false.
The issue was I was behind a zscaler network, so the location of the json resource did not match the one expected for the server. So the XmlHttpRequest failed. I did not want to enable CORS for my site, so I include a default set of data in the page for browsers unable to open the full data set via XmlHttpRequest.
So it was a cross origin issue after all.
I am doing a service call in my javascript which return xml data using xmlHttpRequest.My service call is working in chrome and firefox perfectly and getting the data(it is a https call).But when i try the same with IE11 it is giving status code 12004 .I tried searching it on google i found only one answer saying it means ERROR_INTERNET_INTERNAL_ERROR.
I tried opening fiddler to see the request but when i open up fiddler service call is working fine,but when i close fiddler it is showing same error code.
From the WinINET constant ERROR_INTERNET_INTERNAL_ERROR it appears that the issue is related to the WinINET API which I assume is being used by IE to enable itself to interact with HTTP protocols (including HTTPS) to access Internet resources
http://msdn.microsoft.com/en-us/library/windows/desktop/aa385465(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383630(v=vs.85).aspx
If you really wanted to go deeper and understand the issue, try to download STRACE which is socket/SSL tracer designed to generate LOG for Internet Explorer:
http://www.microsoft.com/en-us/download/details.aspx?id=7643
On a quicker check, you might want to see if your Windows updates is up-to-date to make sure your wininet.dll is the latest and greatest
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.