When I try my code out:
Testing.html -
<script language="JavaScript" type="text/javascript">
function find() {
var iframeEl = document.getElementById('love');
if ( iframeEl.contentDocument ) {
var form = iframeEl.contentDocument.document.getElementById('hi').getAttribute('href');
alert(form)
} else if ( iframeEl.contentWindow ) {
var form = iframeEl.contentWindow.document.getElementById('hi').getAttribute('href');
alert(form)
}
}
</script>
<body onload="find()">
<iframe name="lovez" src="frame.html" id="love">Testingz</iframe>
</body>
Frame.html -
Testing
It will not return an alert box. However on Internet Explorer it will. I have been searching the internet, trying all examples and can't find a simple example that will work in Google Chrome. Am I doing something wrong or is it just Google Chrome?
I've noticed that both the contentDocument and getSVGDocument (for svg objects from svg files) will work fine if the code is from a web server, but when I copy the code to a local file, it will not work.
Here's a sample link with a code I coppied from which works on the web but not from my disk.
Here's the solution I just found from Chrome (thanks to Artem S), i.e. using the --allow-file-access-from-files flag.
Try it without the .document
var form = iframeEl.contentDocument.getElementById('hi').getAttribute('href');
instead of
var form = iframeEl.contentDocument.document.getElementById('hi').getAttribute('href');
The answer from #IsraelGav is correct in the sense that this problem occurs when the code is accessed from a local file but not when accessed from a web server. It is also correct in the sense that using the --allow-file-access-from-files flag can allow the local file to be accessed by Chrome.
However, it misses an important security concern here. Both the concern, as well as an alternative possible solution, were originally described in this other SO answer by #orszaczky. To summarize the alternative solution: On Windows, install http-server (npm install -g http-server) and run http-server from your project directory. On Mac/Linux, run python -m SimpleHttpServer from your local directory. You can now access the locally hosted web site in your browser. On Windows I had to use localhost:8080 while on the Mac I had to use localhost:8000.
By the way, this is not only an issue for Chrome (v49.0) but also for Opera (v35.0), on both Windows and Mac.
Related
I recently tried to update one of my former webapp project in which I need to download files from a server and store them on the device (to access it later).
In order to achieve this I use the navigator.persistentStorage (or navigator.webkitPersistentStorage) and its requestQuota function as seen in https://developer.mozilla.org/en-US/docs/Web/API/LocalFileSystem#using_persistent_storage
The issue is that, when I test my application locally (accessing the index.html via file:///) the requestQuota triggers the "Do you want to allow" chrome popup but when I select "Yes" I get a failure with following DOMError :
{
message: "The implementation did not support the requested type of object or operation."
name: "NotSupportedError"
}
On the other hand, when I access the application deployed on its distant server everything works like a charm.
Beeing aware of the restrictions of the file API in local (https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction#file), I ran thoses tests with a custom chrome :
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ssl-version-min=tls1 --allow-file-access-from-files --allow-file-access --disable-web-security --user-data-dir="C:\tmp\chromeDev"
To test it outside of my application environment, I tried the simple line in chrome inspect :
navigator.webkitPersistentStorage.requestQuota(1024*1024,
r => console.log('success'),
e => console.log('failure : ' + e)
);
On a random local index.html openened in chrome (with file:///) --> "failure".
On a random website (with https://) --> "success".
I downgraded my Chrome and found out all of this problem only occurs since Chrome 86.
Ideally I should upgrade my application to use IndexedDb API, but in the short run a fix or workaround would be quite welcome :)
Thx
Here is my code:
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js">
</script>
<script>
$(function() {
var thing = [];
var bar = $.getJSON('C:\Users\cccompro\foo.json', function(obj) {
for (i = 0; i < obj.length; i++) {
thing.push(obj[i]);
}
});
});
</script>
I'm not sure why it doesn't work. "foo.json" contains an array of objects.
If you are trying the code at Question at Chrome or Chromium browsers, launch the browser instance with --allow-file-access-from-files flag set. Note that open instances of Chrome or Chromium should be closed when you launch the browser or the instance will be launched with the open browser instances' configuration folder, instead of with the flag set. You can launch Chrome or Chromium with an existing instance open and honoring the flag by using --user-data-dir flag with value set a different directory than open instance of Chrome or Chromium.
Technically, it is also possible to write to user file system without using an extension with window.webkitRequestFileSystem. Though using chrome.fileSystem within an extension provides an API designed to achieve the read/write.
See
Jquery load() only working in firefox?
Read local XML with JS
How to Write in file (user directory) using JavaScript?
How to use webkitRequestFileSystem at file: protocol
JavaScript/Ajax Write to File
Using <input type="file"> element
How to print all the txt files inside a folder using java script
You cannot read files directly from the users hard drive without the browsers permission. This would be a huge security issue if you could even though there are ways to allow this (checkout guests answer).
You could however try to make the user select the file and then read it with Javascript.
This is called the HTML 5 file API.
However, this doesn't work for any browser and you probably have to use a server anyway in this case.
For more information on this checkout this or this post.
I'm using window.history.replaceState() to change the query string of a HTML file that was accessed using file:///C:/...
This used to work in Chrome, Internet Explorer and FireFox, but no longer works in Chrome. Not sure when it stopped working. I have Chrome 45.0.2454.85. It still works in the other 2 browsers.
I am getting:
Uncaught SecurityError: Failed to execute 'replaceState' on 'History':
A history state object with URL
'file:///C:/Users/Michael/Desktop/test.html?Q=NewQueryString' cannot
be created in a document with origin 'null'.
Sorry, but this doesn't work in any hosted fiddle. You can copy the code to a local HTML file to see it for yourself:
<html>
<body>
<button onclick="clickme()">Click me</button>
<script>
function clickme() {
window.history.replaceState({ "html": undefined, "pageTitle": "NewTitle"}, "", "?Q=NewQueryString");
}
</script>
</body>
</html>
Obviously I could host this on a server but was trying to keep simple. This is a simple scrum board that we are using hosted by Git. It hits a 3rd party web service to get the data. Any ideas on working around the error.
It stopped working on Chrome 45.
Here I filled an issue on code.google:
https://code.google.com/p/chromium/issues/detail?id=529313
Setting the --allow-file-access-from-files is a good solution if you do just need to run it on your own computer.
I had the same problem. As a workaround, I started Chrome with --allow-file-access-from-files flag.
But think this is not the best solution.
Below is an example of how I'm running:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --app=file: ///C:/APP/index.html --allow-file-access-from-files
If someone find a better solution, please let us know.
(This question pertains to the JS-XSL demo found here)
To briefly tell you what this demo is for; it takes a MS Excel file as input, parses the data, and outputs the data in text-only format. I downloaded the package (zip) and ran it locally, simply by opening the html file with Chrome.
The problem is, I just cannot seem to get over the following error:
Uncaught SecurityError: Failed to construct 'Worker': Script at 'file:///C:/Users/David/Desktop/Xlsx%20Demo/xlsworker.js' cannot be accessed from origin 'null'.
And above error points to line 34 of the html file, which has the following code:
/* I changed the file path from './xlsworker.js' to 'xlsworker.js' */
var worker = new Worker('xlsworker.js');
There are only three files for this demo: the html file itself, and two javascript files, one is named xls.js and the other xlsworker.js. All three files are in the same directory and at the same level.
What's rather baffling to me is, I successfully ran this same demo about a couple months ago! I cannot imagine if I am doing anything differently now. Any insight?
https://code.google.com/p/chromium/issues/detail?id=278883#c9
You are basically prevented by Chromium to use workers on the file:// protocol, you have to host your files and access them through the http:// protocol.
You need a server (even something simple like http://docs.python.org/2/library/simplehttpserver.html)
IMO, the below is a superior answer, because it does not require running a web-server. It's extremely quick and simple.
(the downvote is explained in my Note 5, below)
I have tested and verified that this solution works with the demo linked by the asker, when run locally as described by the asker. Tested on Windows 10, Chrome Stable x64 48.0.2564.103 m.
A script is not allowed to access to your local file system in Chrome. If you'd like to test web workers locally, you have to open Chrome with a special flag.
On Windows, launch chrome with the flag:
chrome.exe --allow-file-access-from-files
After that Chrome will be launched and you can test workers during this session.
Note1: if Chrome is already running when you run this command, the new instance of Chrome will not allow Workers to run-- you must first exit from Chrome (if necessary, use Windows Task Manager to ensure Chrome is not running).
Note 2: the source for this answer (link below) includes the --args flag on Windows, but i have not found the "args" to be necessary on Windows. In fact, i cannot find any documentation of the "args" flag anywhere-- not sure what it does. So i don't include it in the Windows command, above.*
Note 3: For those trying to do something similar on Chrome-Mac, or Windows-Firefox, the link below includes both, along with the Windows-Chrome solution above. But my solution described above is only the Windows-Chrome method.
http://js-workout.tompascall.com/web-workers-and-responsiveness/
Note 4: Be aware that this solution is not the same as running a web-server, but for your purpose it should be a completely adequate solution. Also, be aware that to browse the web with this chrome startup-switch enabled may compromise your local file-security, so it's advised to only use this method for your local file purpose, and disable it for web-browsing.*
Note 5: Google states that using startup flags "should only be used for temporary cases and may break in the future." Web search for chrome startup switches returns about 2,000 hits, so lots of people use them and blog about them. If your need is temporary, then this currently works great.*
We have an internal website for document management. When you choose to open a document, it run the following script to open the file:
012-010-01
<SCRIPT language=javascript>
function opendokument(dokument){
var objAppl;
try{
objAppl = GetObject("","Word.Application");
objAppl.Documents.open(dokument);
}
catch(exception){
objAppl = new ActiveXObject("Word.Application");
objAppl.Visible = true;
objAppl.Documents.open(dokument);
}
objAppl = null;
}
</script>
The problem is that the macros in the document is not running correctly now as we move from Windows XP with Office 2003 to Windows 7 with Office 2007 (See my previous post)
If I run the script locally on my computer or if I open the documents manually macros work properly. How do I get this to work? Any setting I can do in Word or Internet Explorer, or can I rewrite the script on the site that open documents.
Try allowing all kind of scripts in IE. I believe there was something about macroses...
I guess the issues is reated to Security setting of IE.