Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider setting MOZ_HEADLESS env var to 1 #3

Closed
McSneaky opened this issue Jan 16, 2021 · 6 comments · Fixed by #4
Closed

Consider setting MOZ_HEADLESS env var to 1 #3

McSneaky opened this issue Jan 16, 2021 · 6 comments · Fixed by #4
Assignees
Labels
bug Something isn't working

Comments

@McSneaky
Copy link
Contributor

Without adding this environment variable every attempt to connect fails with error:

Error: no DISPLAY environment variable specified
1610804842426	webdriver::server	DEBUG	<- 500 Internal Server Error {"value":{"error":"unknown error","message":"Process unexpectedly closed with status 1","stacktrace":""}}

Not sure if it's intentional or not. Based on readme it feels like it should be headless and not require display output

@tyranron
Copy link
Member

@McSneaky I wonder is it due to latest 0.29.0 upgrade or was true for previous versions too?

@McSneaky
Copy link
Contributor Author

@McSneaky I wonder is it due to latest 0.29.0 upgrade or was true for previous versions too?

Sadly no idea 😐 . The day I made the issue was the first time I ever used it

@tyranron
Copy link
Member

tyranron commented Jan 18, 2021

@McSneaky well, maybe a connection parameters should have some parameters to run in headless mode?

I don't know the webdriver specifics, but in our builds it works OK out-of-the-box:

docker run --rm -d --network=host --shm-size 512m \
	--name medea-webdriver-firefox \
	instrumentisto/geckodriver:84.0.2
GECKODRIVER_REMOTE="http://127.0.0.1:4444" \
WASM_BINDGEN_TEST_TIMEOUT=60 \
cargo test --target wasm32-unknown-unknown --features mockable
    Finished test [unoptimized + debuginfo] target(s) in 0.10s
     Running /home/runner/work/medea/medea/target/wasm32-unknown-unknown/debug/deps/medea_jason-870dc78cb583511a.wasm

Running headless tests in Firefox on `http://127.0.0.1:4444/`
Try find `webdriver.json` for configure browser's capabilities:
Ok
Starting new webdriver session...                 
Visiting http://127.0.0.1:42725...                
Loading page elements...                          
Waiting for test to finish...                     
                                                  
running 143 tests

Also, you can always use -e MOZ_HEADLESS=1 in docker run if your installation does require it.

I don't feel like it's something that should be baked into the image. But mentioning this issue in README makes sense. Would you like to submit a PR?

@McSneaky
Copy link
Contributor Author

McSneaky commented Jan 18, 2021

I don't know the webdriver specifics, but in our builds it works OK out-of-the-box:

@tyranron Hmm, that's odd

The command I used which caused problem: docker run --network=host instrumentisto/geckodriver
When running it with docker run --network=host -e MOZ_HEADLESS=1 instrumentisto/geckodriver then everything is good

Using copy-paste of that first example in https://github.com/jonhoo/fantoccini#examples to test

I'll file in PR to mention it in readme 👍

@tyranron
Copy link
Member

tyranron commented Jan 18, 2021

@McSneaky yeah, the guess was right. wasm-bindgen explicitly requests headless mode when creates a new WebDriver session. Seems that fantoccini doesn't do that out-of-the-box, but you always may specify them explicitly via Client::with_capabilities().

Thanks for the PR!

@McSneaky
Copy link
Contributor Author

Aah, that's cool! Didn't know about wasm-bindgen 😋

I think the issue can be closed, since there are already 2 solutions for it in here and there's no real need to keep it open anymore

tyranron added a commit that referenced this issue Jan 19, 2021
@tyranron tyranron self-assigned this Jan 19, 2021
@tyranron tyranron added the bug Something isn't working label Jan 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants