(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.*
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
I have the following test that needs to verify that clicking a link downloads a PDF. This is especially important as we are using Gatsby, which in turn uses Reach Router's Link Component, and it is relatively easy to misconfigure things so that the router takes over the link and navigates to a 404 page instead of initiating a download.
describe.skip(`Downloads`, () => {
it(`Downloads the expected file`, () => {
cy.visit(pagePath)
cy.getByHref(downloadPath)
.should(`have.attr`, `target`, `_blank`)
.click()
cy.location(`pathname`).should(`eq`, pagePath)
})
})
While this isn't perfect, it does at least check that there is no navigation as a result of clicking the link.
The problem is that when running this test using cy run, which runs the tests in Chrome, the test hangs, due to Chrome's download dialogue.
How can I prevent the test from hanging?
Note that the downloadPath resolves to a pdf in the static directory, for example /static/example.pdf. There is no server component.
Also note that this is a different question to: How can I use Cypress.io to assert that a file download has been initiated without actually downloading?
Actually I searched alot about it and found that
It is not possible to run tests in headless mode with browser extensions installed, because the only supported browser in headless mode is Electron, and Electron doesn't support extensions as stated in the documentation.
Running headless Chrome is not supported yet. See this issue: #488
https://github.com/cypress-io/cypress/issues/488
And this is a an issue not so old it was tagged in Feb 2019
https://github.com/cypress-io/cypress/issues/832
https://github.com/cypress-io/cypress/issues/1235
There are a lot of ways to test this, so it depends. You’ll need to be aware of what actually causes the download, then think of a way to test that mechanism.
If your server sends specific disposition headers which cause a browser to prompt for download, you can figure out what URL this request is made to, and use cy.request() to hit that directly. Then you can test that the server send the right response headers.
If it’s an anchor that initiates the download, you could test that it has the right href property. As long as you can verify that clicking the button is going to make the right HTTP request, there’s nothing else to test for.
In the end, it’s up to you to know your implementation and to test enough to cover everything.
You can prevent the test from hanging by disabling the dialog asking where to save the file. Once you do that chrome will happily download your file and Cypress can continue running your test.
In chrome go to settings->Advanced->Downloads->Ask where to save each file before downloading and make sure it is off.
There are more complicated solutions in the links Apolo provided but this is a quick workaround.
I do cross-origin, cross-frame scripting in one of my projects (end to end testing with client side js without selenium) and that project highly relies on the --disable-web-security flag. From today one of my tests is failing. It tries to load a non-existent remote URI to a child window to check whether an error is thrown by the lib. Well I got an error, but that is a security error, so not what I expect. The other tests are between the karma server on localhost:9876 and a node server on localhost:4444. Those are working properly. My karma contains a Chrome custom launcher with the flag:
customLaunchers: {
"ch": {
"base": "Chrome",
"flags": ["--disable-web-security"]
}
},
As far as I know it needs some sort of user dir too, but the Karma launcher fills that param. Any idea about whether I can fix this or at least what release of Chrome changed the behavior? (I have already sent a bug report.)
Note that the question has nothing to do with Karma. All it does is starting Chrome from CLI with the given flags. A possible fix would be adding another flag, like the --user-data-dir was, but I guess the current changes are intentional and they cannot be undone. I'd like to see where this was discussed. I only found a 5 years old topic in Chromium Google Gorups which discusses this: https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/iivpdszNY3I/3o3BF_mGwlIJ
Using --disable-site-isolation-trials is a partial solution. It works on https://www.google.com, but does not work on Chrome error pages with the error:// protocol.
I created JS & HTML5 Blank App with Visual Studio 2015. When running it in VS debugger in "Local Machine" mode, I get the following error message:
Application is not currently attached to a script debug target that
supports script diagnostics
Just ignoring the error is not workable as at least breakpoints and console.log("text") do not work.
I'm having default options in VS.
I am running normal Win10, with automatic updates on.
Reinstallation of VS2015 did not solve the issue.
This worked for me although I was doing something slightly different. I got the same error message using IE 11 accessing a HTML file from my local file system (was mucking around with HTML). Seems IE developer tools don't much like this mode of operation (why?!). Here's my story...
File on my local windows laptop:
c:\temp\test.html
Can be opened in these browsers:
URL: file:///C:/Temp/test.html (in chrome)
URL: C:\Temp\test.html (in IE 11)
In Chrome tools commands in the console can be run no problem e.g.
console.log("hi");
In IE developer tools this fails with the message cited by the op.
I had a reverse proxy installed on my laptop (nginx) so tried serving the file up via HTTP and this fixed the issue with IE. Here's how I would access the file via HTTP via the proxy:
http://localhost:9092/temp/test.html
For reference here's my nginx.conf (but any other proxy would I expect work fine)...
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
server {
listen 9092;
server_name localhost;
location /temp {
alias "C:/temp/";
}
}
}
In my case (VS 2017 not 2015), the option shown below had somehow become unticked (I'm blaming an update). Before ticking this I was getting the same error as the OP; after ticking it, all is well again.
NB I'm debugging the Javascript within a WebBrowser control hosted in a Winform.
I finally got this solved with the help of Jack-Zhai in msdn forum. So, the summary of my journey:-
Problem:
- Running JS UWP blank app in debug mode & local machine w default settings in VS2015 generates a warning "Application is not currently attached to a script debug target that supports script diagnostics" into JavaScript console. Breakpoints do not work, adding console.log("here") does not write anything to console
Solution trial 1:
- changing and playing with VS2015 settings; the problem still exists
Solution trial 2:
- reinstalling VS2015; the problem still exists
Solution trial 3:
- reinstalling Windows10 - all applications deleted but user data not
- installing VS2015
=> Problem solved; debugging blank app works, and console.log("test") works
I have a #JavaScript annotation in my application to load a .js file from the classpath.
Now I've made an update to the file and redeployed (locally), but I always get the old version back. I've tried reloading everything (ctrl+R, ctrl+F5) but that doesn't work and also I wouldn't want the users to have to do that.
A trick I used in the past (without Vaadin) was to append a request parameter with the version (e.g. ?version=1) and update that so that the URL changes. But apparently that isn't allowed for the #JavaScript annotation (Vaadin doesn't even try to load the file).
I have overcome this by utilizing the resourceCacheTime parameter of the Vaadin servlet configuration:
#VaadinServletConfiguration(ui = MyUI.class, resourceCacheTime = 0)
Although it has its limitation as described in my answer to another question here.
This is browser feature to localy cache JS files, nothing to do with Vaadin.
As you figure it out yourself: If you want to make sure users have latest version of JS file, you should rename JS file name to: script_buildNumber.js.
Use the Chrome's incognito feature (and not use it when visiting spicy/unpleasant websites).
Just open your browser in Incognito mode https://support.google.com/chrome/answer/95464?hl=en and the browser will cache nothing.
Other browsers have this feature as well (Opera, IE, Firefox, Safari).
As I noted in my comment on the question on January 12th, renaming the file worked. This seems to be currently the only way, although it's far from ideal.