#selenium

anyone familiar with google-chrome v59.. i'm trying to get my head around how/what the sel webdriver does regarding google-chrome as well as chromedriver...

what do you mean

does webdriver.Chrome(...) instantiate/create an instance of chromedriver..

i see different chromedriver --port=foo appearing in the procTBL..

webdriver.Chrome will create an instance of remote.webdriver

so something is kicking off the process

yes

python

specifically.. what..

python uses an http client to communicate to chromedriver, but it also has a Service class that actually runs the chromedrivre process

from selenium import webdriver

driver = webdriver.Chrome(

out1=driver.get(url)

Service class starts chromedriver. python then sends an http post /session to the chromedriver, and then chromedrive starts up Chrome web browser with certain settings so that it knows automation is about to happen.

i would imagine that one of these.. kicks off the chromedriver.. and i'd suspect the webdriver.Chrome..

chromedriver is basically an http server that proxies HTTP calls between the client (python or whatever language) and Chrome

ok.. it resides "between" the py/sel and the chrome app

yes. it's a program that receives HTTP requests from a language, and then sends messages to chrome, and relays the response from Chrome back to the client.

is there a way for the "sel" client to know the chromedriver port?

it knows it internally, are you wanting to know it after it starts?

i never had to worry about the chromedriver port

in my case.. i'm finding that i have leftover chrome artifacts.. that I thought would/should be killed/deleted once the process quits.. but they're sitting there in the procTBL..

but i think you can configure it

you can get the port via driver.service.port

but python kills the service when the python thread is killed or driver.quit() is called

mydog2 are you calling driver.quit(); it will terminate the chromedriver and Chrome

various articles have stated... driver.quit() will kill off the associated children processes.. but I still have chrome related "cruft"

if you're using it through standalone server, that's a different ballgame

dude-x, -- um.. no.. it's not!

latest version also of python client was patched to fix some issues

if you have a reproducible test case we can look at it, otherwise there's not much that can be done

i've generated a fresh centos install over the last few days. with google-chrome-stable v59 for the --headless feature -- no Xvfb

what's not being cleaned up chromedriver or Chrome?

in my test.. I call driver.quit.. now.. keep in mind.. i run a bunch sequentially.. but at some time.. the driver.quit doesn't function correctly

dude-x, --both

scroll down to where I pasted a chunk of the procTBL

line 150 or so

are you running the script locally?

mydog2 i suspect....

yeah...

that driver.close() may be causing issues

remove it

and this is killing me.. as i don't have a full grasp

close is only for closing new windows

if you have more than 2 windows, driver close is good to close that window

but in general, you want to call driver.quit()

in fact, i always wrap driver.close() to check that window handles is > 1, otherwise no-op

mydog2: are you starting chromedriver before running your script?

`the process starts by starting the >>>>google-chrome-stable --headless --disable-gpu --remote-debugging-port=9222 http://localhost &`

nope he just defines chromeoptions

lucast, -- no... i start google-chrome-stable

why?

google-chrome-stable --headless --disable-gpu --remote-debugging-port=9222 http://localhost &

chromedriver handles that for you

lucast.. i've cobbled all of this from different articles/testing..

lots of misinformation on the web

if youre starting it that way first, then you're going to have 2 instances of it going

because the python/chromedriver will start one too

which is why i ask questions here!

i've never manually started a chromedriver

you only need to manually start it if you're wanting to use it as a remote endpoint

only time i write 'chromedriver' in the terminal is to just check that the PATH is correct

^

certainly never start chrome itself

lucast you mean indepdent of selenium standalone server?

yeah

so.. should i just not start chrome.. as well as as chromedriver.. just assume that the test will fire it off?

yeah you can do that too, but i guess only if you have a need for something barebones.

using 'http://127.0.0.1:9515' as the remote end

mydog2 yes.

ok.. i'll retest doing that..

mydog2: yes python handles all of that

make sure you kill off all your current processes so you know if knew ones are left hanging out

my goal.. to be able to have multiple simultaneous clients firing off test urls..

killall chromedriver

you can do that

yes you can do that. multiple processes will each have their own chromedriver, and instance of chrome

as fast as possible.. unfortunately.. the target url is/are dynamic script.. so sel+py+chrome is more or less required

or you could use one chromedriver with a bunch of remote driver instances talking to it... but lets not get into that

let's keep it simple

lucast how would you tell the python client not to kill chromedriver?

dont call driver.quit?

hm, how can i turn down the loglevel= -debug false stills print info messages i don't want

?

rerunning to setup the test... takes a bit

so.. if i get this working.. where do i send the oj?

OJ is free once more.

mydog2 send coconuts to NJ.

is there a way of checking if an element is being visually displayed? I know you can check visibility but thats not quite the same

lucas-jones-sl is the element... an image?

dude-x: i was going back to starting chromedriver separately and using remote

What is the purpose/meaning of "enablePassThrough"?

lucas-jones-sl: what is ‘visually displayed'?

As in, the element can be found on the page with `find_element_by_xpath` but its not actually visible when you look at the page

lucas-jones-sl: that’s presence, then

as in, present in the DOM

and that doesnt mean its visually displayed

presence is the element exists in the DOM

like many divs that impart structure

can you append this to your xpath

not(ancestor::*[contains(normalize-space(@style), 'display: none') or contains(normalize-space(@style), 'DISPLAY: none') or contains(@style, 'display:none') or contains(@style, 'DISPLAY:none')]) and

i feel another factlet needing to be added

WE1LS: we can’t possibly know, we aren’t xpath parsers. Try it and see

i already use this xpath segment. it is how i make sure an element is in the DOM and also visible

WE1LS: oh, I see. In that case, your xpath doesn’t cover even half the things that affect visibility

and afaik those are all covered by the driver's way of determining

yep

selenium visibility check has many checks

[13selbot2] 15Jarob22 opened pull request #60: try it and see factlet (06master...06try-it-and-see) 02https://git.io/v7U9N

Added a Python snippet: https://gist.github.com/f58dc632e71a810c1aace6f... with comment: "Why is this evaluating to `True` even though the element is not being rendered?"