Closed GordonSmith closed 5 years ago
@GordonSmith thanks for stopping in. good news: we already have that feature.
it looks like our README needs an update, but if you were to run mocha-chrome
on the command line, you'd see output that looks like this: https://github.com/shellscape/mocha-chrome/blob/0f596aa942babf6b95bce14707a7f4ccc6efcfb8/bin/mocha-chrome#L24
--chrome-flags A JSON string representing an array of flags to pass to Chrome
That means you'd have to run it like so:
mocha-chrome --chrome-flags ["--allow-file-access-from-files"]
To get that value, you need to stringify
a JSON
array. Like so:
JSON.stringify(['--allow-file-access-from-files']);
I just found that in the sources - but am having difficulty getting it to work:
.\node_modules\.bin\mocha-chrome --chrome-flags ["--allow-file-access-from-files"] .\test.html
undefined:1
[--allow-file-access-from-files]
^
SyntaxError: Unexpected number in JSON at position 2
at JSON.parse (<anonymous>)
at Object.<anonymous> (C:\Users\gordon\git\hpcc-js\node_modules\mocha-chrome\lib\cli.js:71:26)
at Module._compile (module.js:635:30)
at Object.Module._extensions..js (module.js:646:10)
at Module.load (module.js:554:32)
at tryModuleLoad (module.js:497:12)
at Function.Module._load (module.js:489:3)
at Module.require (module.js:579:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (C:\Users\gordon\git\hpcc-js\node_modules\mocha-chrome\cli.js:20:3)
try mocha-chrome --chrome-flags '["--allow-file-access-from-files"]'
I neglected to wrap that array in quotes. It's supposed to be a string.
Thats what I started with (looking at the sources), still no joy:
.\node_modules\.bin\mocha-chrome --chrome-flags '["--allow-file-access-from-files"]' ./test.html
undefined:1
[--allow-file-access-from-files]
^
SyntaxError: Unexpected number in JSON at position 2
at JSON.parse (<anonymous>)
at Object.<anonymous> (C:\Users\gordon\git\hpcc-js\node_modules\mocha-chrome\lib\cli.js:71:26)
at Module._compile (module.js:635:30)
at Object.Module._extensions..js (module.js:646:10)
at Module.load (module.js:554:32)
at tryModuleLoad (module.js:497:12)
at Function.Module._load (module.js:489:3)
at Module.require (module.js:579:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (C:\Users\gordon\git\hpcc-js\node_modules\mocha-chrome\cli.js:20:3)
welp, looks like a bug then :) we'd welcome a pull request, would be a solid first contribution!
I suspect your argv processor is eating some of the quotes. FWIW this works inside the package.json scripts section:
"test": "mocha-chrome --timeout 10000 --chrome-flags \"[\"\"--allow-file-access-from-files\"\"]\" ./test.html"
(and working damn well!!!) there might be an argument for defaulting that flag on by default as its only going to catch folks out I suspect.
glad it's working for you! 👍
it certainly could be an issue with Windows and minimist. I'm certain they'd appreciate it if you provide a failing test case for them.
we do know that it works in CI (Linux) and on Mac. I added some tests for that just now: https://github.com/shellscape/mocha-chrome/blob/master/test/cli.js#L53-L57
Yup will be closing the linux + travis loops here next. Will try and distill the issue once I have a known working base.
Quick update - this is what I am now using and is working on windows + linux:
"test": "mocha-chrome --chrome-flags \"[\\\"--allow-file-access-from-files\\\"]\" ./test.html"
Which may be technically correct (seem to remember jumping through similar hoops in some CMAKE files).
I think it's a good idea to always pass --allow-access-to-files
by default, if not detecting that the URI is a file protocol since without it, it is gaurenteed to fail.
@nathanboktae that's strange as the tests all run from file://
without that argument and seems to work without issue. what's the specific scenario/condition in which it'll fail?
Good point. Looks like I'm mistaken on exactly how that flag operates.
@shellscape If your JavaScript dynamically loads a file (like a JSON file) it will fail without it. For example if your JS contained the following code:
var xobj = new XMLHttpRequest();
xobj.overrideMimeType("application/json");
xobj.open('GET', 'my_data.json', true); // Replace 'my_data' with the path to your file
xobj.onreadystatechange = function () {
if (xobj.readyState == 4 && xobj.status == "200") {
// do stuff
}
};
xobj.send(null);
@GordonSmith OK so that must be isolated to JS then. Next step is to find out if there are any detriments to adding that flag by default. If it doesn't cause any secondary issues, and it's not a security risk (because I'm wondering why chrome is hiding that support behind a flag) then we can add it as a default. Otherwise, we can add documentation around it.
In the real world it is a security risk - typically when someone gets tricked into opening a html page as part of an email attachment. Maybe elevating it to being a "supported" flag (and documenting it) would be more appropriate? (Just my 2c - no strong feelings eitherway)
Just leaving a note for anyone trying to use this in Travis CI: Check the Travis CI Chrome docs and note that it's necessary to pass the --no-sandbox
flag like so:
mocha-chrome http://mytest --chrome-flags '["\"--no-sandbox\""]'
Operating System: Windwos 10
Node Version: 8.9.0
NPM Version: 5.5.1
mocha Version: 2.2.41
mocha-chrome Version: 1.0.1
[x] This is a feature request
[ ] This is a bug
For Features; What is the motivation and/or use-case for the feature?
I would like to pass the
--allow-file-access-from-files
command line argument to the headless instance of chrome. My test web page dynamically loads a json file and I use the above argument when I load the page viafile://...