This bug requires manual review: DEPS changes referenced in bugdroid comments.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
hi dvallet,
is there an easy way of telling when a new (headless) version of chrome is
available for testing? the sub-version of v59 on the dev channel hadn't
changed for a while, the last time i checked.
Thanks.
-dh
dvallet@ - can you please confirm if this has been tested in canary, baked in for at least 24 hours? Is there enough test coverage for this change? I see a bunch of changes after comment 13, so can you please confirm what changes will be in this merge?
Current state is that --headless in Windows had to be reverted due to https://bugs.chromium.org/p/chromium/issues/detail?id=714841
I'm investigating how to decrease the size and see if I can reland the features.
Unfortunately, this may mean Headless for Windows would not ship in v59, but I'll see if I can push it asap to the dev channel.
Does that mean you still need a merge? If this has not been fully tested yet on Canary or Dev, I recommend delaying it until M60 to ensure it goes through the full cycle.
hi dvallet,
i was flabbergasted today to see that chromium was now running headless.
eventually i realized that i'd (automatically) upgraded to Version
60.0.3080.5 (Official Build) dev (64-bit), and apparently the headless
option is functional in that release (as comment 26 suggests). i am using
the headless version to do some webscraping. what i've found is that while
the headless version runs invisibly and apparently correctly, it fails to
download a PDF, but if i comment out the headless option it successfully
downloads the PDF. i've attached the python script.
playWithSeleniumMinimzed.py is a reduced version of a larger program, so
there's some redundancy, but you will see that it basically prompts the
user for a choice of publisher. the only valid choices in the minimized
version are '0', which will select elsevier as the publisher, and 'q',
which will terminate the program. if you choose 0 as the input, you should
be able to get one PDF (on animal models of epilepsy) downloaded to the
directory 'dfd' (which you will need to change in the code) if you run in
normal mode. but if you uncomment the line that adds 'headless', you will
see that chrome runs headlessly without a hitch, but does not download the
PDF, either to 'dfd' or to the normal default download directory. the
verbose log is saved in the 'dfd' directory as well. i have verified these
results both on windows 10 and windows 7, with python 3.5.
hopefully this will be helpful to you. thanks for all your work.
-dh
hi dvallet,
i've had problems attaching files before, but it appeared to me that one had been attached this time. i'll try again below.
in relation to your explanation, that makes sense. but downloading is an important part of what i want to do with headless chrome. is it currently planned for a specific release?
-dh
hi dvallet,
the failure to download was precisely the issue i encountered, and #696481
explains the issues very clearly. since it's a recognized issue, there's
probably no point in my attaching code that demonstrates it. it was unclear
when the option to download files in headless mode will be available,
though. downloading is critical for my intended use case, so having it
available as an option at least is important (even if the default is to
turn it off). any insights?
-dh
Hey David, I saw that you commented on the download bug, thanks for doing this!
I'm sure it will be dealt with, but first there's some work to specify the feature more clearly. Feel free to further comment there.
hi dvallet,
when i look at chrome on my PC, i see it is 60.0.3095.5. headless doesn't
work, which suggests that the changes described in C#33 are not yet
released. is there an easy way to tell when changes mentioned in a comment
like C#33 are incorporated into a particular release of chrome?
thanks in advance.
-dh
You can use paste the git hash to omahaproxy.appspot.com to check which Chrome build includes the CL.
A CL roughly takes a day before ended up in Chrome Canary.
hi dvallet,
i'm finding that the current dev version of chromium (60.0.3107.4) still
doesn't download files properly in headless mode, although it works fine in
the visible mode. when i run code with the headless option commented out,
i am able to download a file, after navigating to a specific button, with
the code:
btns = driver.find_elements_by_id("pdfLink")
driver.get(btns[0].get_attribute('href'))
time.sleep(15),
a file is downloaded properly to the default directory, using the options
set by these lines:
options = webdriver.ChromeOptions()
prefs = {"download.default_directory": dfd,
"plugins.always_open_pdf_externally": True,
"disable-extensions": True, "download.prompt_for_download": False,
"download.directory_upgrade": True}
options.add_experimental_option("prefs", prefs)
#options.add_argument("headless") -- commented out
options.add_argument("disable-infobars")
driver = webdriver.Chrome(chrome_options = options)
when i change the single line required to start headless by removing the #
at the beginning, i find that the navigation works OK; btns[0].get('href')
contains the proper URL for the file i'm trying to download, but
driver.get(btns[0].get_attribute('href')) no longer works -- nothing is
downloaded.
i'm attaching the whole program (it uses selenium and chromedriver). i've
had problems attaching files in the past, so let me know if you can read it.
i'm baffled. is this a problem with chrome, or with chromedriver, or
something else?
thanks in advance.
-dh
Unless it is merged (you will see merge comments), "Fixed" generally means it is fixed on trunk. That means it will be fixed in the next canary and over time, in the respective release channel.
It seems to be partially working on Windows in 59.0.3071.86. I get a blank UI shell, but unit tests (Karma) can run successfully.
However, things like --dom-dom and --screenshot do not seem to be functional yet.
It looks like the Merge-Review-60 label got added before M60 was actually branched on 5/26. Removing it for now, if there are changes that you want merged into the branch, feel free to add it back and along with the CL's to review.
Comment 1 by bugdroid1@chromium.org
, Feb 13 2017