--headless --disable-gpu --repl results in loop printing of >>> {"result":{"type":"undefined"}}
Reported by
emil.fih...@gmail.com,
Jul 25 2017
|
|||
Issue description
Chrome Version : Google Chrome 59.0.3071.115
URLs (if applicable) : any
Other browsers tested: not applicable
What steps will reproduce the problem?
(1) Start Chrome with --headless --disable-gpu --repl and optionally an url
What is the expected result?
A shell
What happens instead?
>>> {"result":{"type":"undefined"}} is printed over and over again
Please provide any additional information below. Attach a screenshot if
possible.
Video of behaviour: https://emil.fi/jako/videot/2017-07-25_11-07-44_W857n0XS.mp4
,
Jul 25 2017
Tried on a friend's computer with Ubuntu, exact same behaviour.
,
Jul 25 2017
,
Jul 29 2017
This is caused by the google-chrome startup wrapper. google-chrome in Ubuntu links to /opt/google/chrome/google-chrome which is a bash script that starts /opt/google/chrome/chrome Lines 44-46 reference this security bug http://crbug.com/376567 . The fix was to pipe /dev/null to stdin. When the repl starts, it receives a constant stream of \x0 bytes from /dev/null which cause the behavior above. Commenting out these lines fixes the issue. A workaround is to execute the chrome binary directly and not use the startup script. /opt/google/chrome/chrome --headless --disable-gpu --repl https://google.com/
,
Jul 29 2017
@rysnxedg... Ah, much thanks for explaining this. I also now understand why there are the cat processes as child when running Chrome (though it (that security bug solution) is extremely hacky, lazy and bad and should be fixed right away). From a user's standpoint those cat processes seem like (security) issues that don't exactly raise confidence in the software. Anycase, a possible solution to this current issue here is to just warn the user about borked input when the startup script sees "--repl" in the argument list by informing about the pipes and/or recommending to use the binary directly.
,
Jul 30
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/67fecf88ed445726d770d6e7e6b0cf746a995efb commit 67fecf88ed445726d770d6e7e6b0cf746a995efb Author: Fredrik Söderquist <fs@opera.com> Date: Tue Sep 18 08:52:10 2018 Improve EOF handling in the headless REPL When the REPL encounters an EOF, it can start spinning on just generating a lot of empty ("") expressions. Instead quit if an EOF is received and there's an empty expression. If the expression is not empty it will still be evaluated. This helps certain non-interactive use-cases. Bug: 748419 Change-Id: Ica91f2164361bd6891f71e25fbdba0773c6c9941 Reviewed-on: https://chromium-review.googlesource.com/1225764 Reviewed-by: Eric Seckler <eseckler@chromium.org> Commit-Queue: Fredrik Söderquist <fs@opera.com> Cr-Commit-Position: refs/heads/master@{#591979} [modify] https://crrev.com/67fecf88ed445726d770d6e7e6b0cf746a995efb/headless/app/headless_shell.cc |
|||
►
Sign in to add a comment |
|||
Comment 1 Deleted