I am developing JavaScript chat. I have done the prototype, and it seems to work pretty well. But our client says that it doesn't work. We both use IE7 on PC, and try to run the same JavaScript code. I have no idea about the reason.
On my client's machine there is "object is expected" error. I have thought about security restrictions, and tried to make security level higher in my IE, but in this case the script doesn't run and there is no error messages. I am running the script on the remote server.
Clients machine may be running within a group policy which for security reasons can restrict execution of scripts. Hence the client may need to include your prototype as part of their trusted sites and relax restrictions on trusted sites
Are you able to provide any more details about the specific error? Are you sending the client a zipped up version of the solution or is it hosted somewhere?
From the IEBlog; you could try using the Microsoft Script Debugger (see post)
One thing you may find, especially with IE is the error that is reported is actually caused by a previous error in the code.
Try running your javascript through jslint to ensure that it is well formed.
In Firefox with [firebug], enable strict warnings in the console.
Related SO posts.
debugging-javascript-in-ie7.
debugging-javascript-for-ie6.
Edit::
One thing to look for is comma's after the last element in an array, IE seems to ignore the closing brace } and keep adding following code to the array. Firefox gracefully just assumes that you forgot it.
If you're running the code from localhost and he's running it from a remote server then it could be a timing issue - some script could be running before the page has finished loading that's causing a problem on a slow connection that is hidden on a fast connection.
You can get this error if you try to use an exernal script file that the client's browser can not access.
Example :
<script src="http://localhost/scripts/freelib.js" language=Javascript> </script>
You can access freelib.js on your machine, but running it from any other machine it wouldn't work.
Are you sure all the scripts are being loaded? I've seen that error message before when some or all aren't loaded (maybe they didn't get deployed). Try manually copying the addresses of all the js files from the source and pasting them into the address bar to make sure that the browser can actually access them.
Can you run the page on your client's machine in Firefox? The firefox console should give you a more detailed error message than IE will.
Related
While running VS Code Live Server (Go Live), the browser is crashing with the below mentioned error. I am using Google Chrome as default. I re-installed VS Code after uninstalling completely (from cache even), restarted browser, and then restarted PC as well with no use. When I checked "Use Local Ip" in LiveServer>Settings:, server is taking too long to respond and eventually fails to load the page (Error: "This site can't be reached"). Another important thing is that Chrome is opening every other website properly. This problem exists only when opening VS Code Live Server. Below is the error code:
Chrome Browser Error:
"Aw, Snap!
Something went wrong while displaying this webpage.
Error code: STATUS_BREAKPOINT"
Another popup is also showing up simultaneously:
"DevTools was disconnected from the page.
Once page is reloaded, DevTools will automatically reconnect."
(This didn't seem like a bug in the code of script.js)
Found the Solution:
Indeed it is a bug in the code of script.js.
If you are having exactly the same problem as I described, let us first see what we don't need to do, as I found these suggestions everywhere, and none will work when both VS Code and your browser are perfectly fine (they only appear to be not working):
No need to restart or reinstall VS Code.
No need to restart or reinstall browser.
No need to restart the PC
No need to disable browser extensions or VS Code extensions.
No need to change LiveServer Custom Browser; you can keep it
default.
No need to change LiveServer>Settings>Use local ip or Use browser
preview (you can keep them both unchecked if they are already
unchecked by default)
However, if you use firefox, console shows the error: "Uncaught out of memory"
Here, I got the first hint. Firefox at least told me to look at memory, but it is not about the memory we think. It is not about multiple tabs opened, lack of disk space, unstable disk, etc. It is the accidentally generated infinite loop in the code which is causing the memory problem (check your code carefully to find it).
In my case, I accidentally didn't tell it to execute the next iteration (i.e., missing counter update, increment, i++) and it is stuck in the same while loop forever, as the condition is satisfied forever without any counter update.
After fixing the code, the below error might show up in the console. Just refresh the page and it will go away.
"favicon.ico:1 Failed to load resource: the server responded with a status of 404 (Not Found)"
Note: Unless you fix the code or comment it out, other linked files (like .html) in the folder wouldn't work either.
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.
I have been stuck on this for a couple of weeks now and this is a follow on from SO question Delphi REST Debugger Returns Error 429 Too Many Requests but Browser Returns JSON as Expected
I was wanting to get the content of a url response using the TNetHTTPRequest and TNetHTTPClient components. I was continually getting 429 errors “too many requests”. When using Firefox Inspect Element to look at network and storage, I discovered that I needed to receive cookies and then send those cookies with my request. Unfortunately, one of the cookies essential to the website content seems to be dependent (I think) on the execution of javascript. I went back to first principles and dropped a TWebbrowser on a form (VCL) and sure enough browser shows a javascript error “Expected Identifier”.
When I use the TWebbrowser in FMX it does not throw an error it just does not return the website contents at all and remains blank. I need FMX as I will be in a cross platform mobile environment.
The URL is https://shop.coles.com.au/a/national/home
I use Delphi Community Edition 10.3.3 Rio.
The URL returns perfectly in commercial browsers Firefox, Safari, Chrome and even CEF4Delphi. Unfortunately, I can’t use CEF as I need cross platform.
I would like to know how to get the website content returned to the browser (or even better NetHTTPClient) without script errors and how to access the browsers current cookies.
Any help will be most appreciated.
Thanks,
John.
URL returns perfectly in commercial browsers ... without script errors and how to access the browsers current cookies
If you'd inspect the network traffic (F12 > Network, then requesting your URL) or use uMatrix (to block everything that doesn't belong to the domain by default) you'd see the JS does at least one XHR to amazonaws.com. Your HTTP transfer alone (as done by TNetHTTP*) works fine and you get the same resource that each internet browser gets.
However, you don't operate with what you got (in contrast to the internet browser, which also automatically parses the HTML, sees JS resources, and executes them). TWebbrowser does not what you take for granted most likely due to security settings (try to get an error console in there, preferably F12 again). You need to do the same: parse the HTML resource for JS URIs, requesting those and executing what you get, while still providing the same cookie environment.
For executing JS you could use Chakra or mORMot or BESEN. It's challenging at first, but the more you understand about HTTP (including cookies) and a JS engine, the more you'll see why "things work" in one situation and not in another. There's a reason why an internet browser is a very complex software and not just a downloader.
As per this forcing IE11 Quirks mode might cure your problem already when using TWebBrowser:
TBrowserEmulationAdjuster.SetBrowserEmulationDWORD(TBrowserEmulationAdjuster.IE11_Quirks);
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.
I am using jquery and running a html file on my local machine (no server).
The following works on firefox but not on chrome:
$('#result').load('test.html');
It seem to be something wrong with the path.
Anyone know how to sort this out without having to add an absolute path please?
Thanks
Ajax requests cannot be sent cross-domain. On your local machine, every request is cross-domain to the browser, so no Ajax can be used at all. Chrome is a bit more strict than Firefox here. There is no solution, you will just have to upload it to a web server or install something like Apache on your local machine for testing purposes.
Typically, AJAX requests cannot be sent cross-domain, however, if you're just looking to access a local file, you could try enabling one of Chrome's secret flags. Specifically:
--allow-file-access-from-files
With any luck, you should be able to get things working by changing your chrome shortcut to the following:
chrome.exe --allow-file-access-from-files
I'm not sure if that flag is enabled in all builds of Chrome (I am presently running chromium 10), but it definitely works: I've been using it to enable file-save access in TiddlyWiki.