Support Forum
I am playing around with your trial webdriver and I have noticed a problem.
I created a docker container where I want to run the tests but they fail if I run them in the a docker container.
If I run the tests on a unix host similar to the docker container all good.
I am getting preload errors "fail 1 - Preload of https://127.0.0.1:88/build/js/shared.js has failed". It seems like in the docker container something is going wrong. Some other times, some other errors are displayed. The errors are not consistent.
In both cases, the docker container is providing all the files for the tests. (port 88:88 is mapped).
Attached are screenshots from the 2 hosts(one is the main host, the other one is the docker container - this fails)
PS: I am playing around with siesta-5.3.2-trial. webdriver--version is in the screenshot for both host/docker
Any ideas?
I created a docker container where I want to run the tests but they fail if I run them in the a docker container.
If I run the tests on a unix host similar to the docker container all good.
I am getting preload errors "fail 1 - Preload of https://127.0.0.1:88/build/js/shared.js has failed". It seems like in the docker container something is going wrong. Some other times, some other errors are displayed. The errors are not consistent.
In both cases, the docker container is providing all the files for the tests. (port 88:88 is mapped).
Attached are screenshots from the 2 hosts(one is the main host, the other one is the docker container - this fails)
PS: I am playing around with siesta-5.3.2-trial. webdriver--version is in the screenshot for both host/docker
Any ideas?
- Attachments
-
- Screenshot_41.png (101 KiB) Viewed 5284 times
-
- Screenshot_40.png (217.77 KiB) Viewed 5284 times
-
- Screenshot_38.png (235.96 KiB) Viewed 5284 times
Hi,
Hard to say, the preload failure indicates its a legitimate 404 error, detected by browser and reported by Siesta. Possibly a file is just missing? or some access directives in the webserver aren't correct?
Can you try reproducing this error with Siesta 5.3.1 ?
Hard to say, the preload failure indicates its a legitimate 404 error, detected by browser and reported by Siesta. Possibly a file is just missing? or some access directives in the webserver aren't correct?
Can you try reproducing this error with Siesta 5.3.1 ?
Read the API documentation
No files are missing. I thought so too initially. In the tests that pass (the webdriver is on the server(not in the docker)) but the rest is delivered by the docker container.nickolay wrote: ↑Sun Mar 22, 2020 12:27 pm Hi,
Hard to say, the preload failure indicates its a legitimate 404 error, detected by browser and reported by Siesta. Possibly a file is just missing? or some access directives in the webserver aren't correct?
Can you try reproducing this error with Siesta 5.3.1 ?
I didn't tested with 5.3.1. A few months ago when I tried the CI setup with docker it worked well (I think it was the 5.2.3, I have to check).
Another thing I have noticed is that ALWAYS the second preload file fails. So no matter how I order these, it's always the second file that fails.
let preload = [
'/build/runtime.js',
'/build/js/shared.js',
'/build/js/common.js',
'/build/js/testing.js'
];
project.configure({
viewDOM: true,
mouseMovePrecision: 100000,
preload: preload,
...
This sounds very weird, the order of preloads shouldn't matter of course.Another thing I have noticed is that ALWAYS the second preload file fails. So no matter how I order these, it's always the second file that fails.
This is possible with puppeteer (if error is reproducible with puppeteer launcher). The puppeteer's `Page` event has various request/response related events, which can be logged I guess: https://devdocs.io/puppeteer/index#event-requestIs there a way to debug the console.log of the browser? or even the network requests of the browser?
You will need to modify "bin/siesta-launcher-all.js" for that, search for:
this.puppeteerPage.on('console', msg => {
this.debug("console.log() from page " + this.id + " " + msg.text())
})
Read the API documentation
If I run it with puppeteer then it seems to work. Never tried it with puppeteer.
Now webdriver vs puppeteer, would you recommend using puppeteer over webdriver?
Now webdriver vs puppeteer, would you recommend using puppeteer over webdriver?
root@60653ef88db2:/srv/tools/siesta-5.3.2-trial/bin# ./puppeteer 127.0.0.1:88/senchaws/packages/local/ipdu/tests/indexr-no-ui.html --browsesable-gpu --browser-arg no-sandbox
This is weird again. Changing launcher should not affect test suite results generally, especially in regard of 404 errors..
Puppeteer launcher is basically same thing as WebDriver + headless Chrome. Using it is fine. It can be a bit faster also.
There are very subtle differences for puppeteer though, for example, afaik, it uses on-demand scroll bars (Mac style).
Puppeteer launcher is basically same thing as WebDriver + headless Chrome. Using it is fine. It can be a bit faster also.
There are very subtle differences for puppeteer though, for example, afaik, it uses on-demand scroll bars (Mac style).
Read the API documentation
Ok, I get the feeling it has something todo with the chrome installation that webdriver is using.
I just gave it a shot with firefox and ... it works
I just gave it a shot with firefox and ... it works
root@60653ef88db2:/srv/tools/siesta-5.3.2-trial/bin# ./webdriver 127.0.0.1:88/senchaws/packages/local/ipdu/tests/indexr-no-ui.html --headless --browser=firefox