#selenium

/

      • mydog2
        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...
      • dude-x
        what do you mean
      • mydog2
        does webdriver.Chrome(...) instantiate/create an instance of chromedriver..
      • i see different chromedriver --port=foo appearing in the procTBL..
      • dude-x
        webdriver.Chrome will create an instance of remote.webdriver
      • mydog2
        so something is kicking off the process
      • dude-x
        yes
      • python
      • mydog2
        specifically.. what..
      • dude-x
        python uses an http client to communicate to chromedriver, but it also has a Service class that actually runs the chromedrivre process
      • kpschmidt joined the channel
      • mydog2
        from selenium import webdriver
      • driver = webdriver.Chrome(
      • out1=driver.get(url)
      • dude-x
        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.
      • mydog2
        i would imagine that one of these.. kicks off the chromedriver.. and i'd suspect the webdriver.Chrome..
      • dude-x
        chromedriver is basically an http server that proxies HTTP calls between the client (python or whatever language) and Chrome
      • mydog2
        ok.. it resides "between" the py/sel and the chrome app
      • dude-x
        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.
      • czart__ joined the channel
      • mydog2
        is there a way for the "sel" client to know the chromedriver port?
      • lucast
        it knows it internally, are you wanting to know it after it starts?
      • kpschmidt has quit
      • dude-x
        i never had to worry about the chromedriver port
      • mydog2
        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..
      • dude-x
        but i think you can configure it
      • lucast
        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
      • mfsi_ankitm has quit
      • dude-x
        mydog2 are you calling driver.quit(); it will terminate the chromedriver and Chrome
      • mydog2
        various articles have stated... driver.quit() will kill off the associated children processes.. but I still have chrome related "cruft"
      • lucast
        if you're using it through standalone server, that's a different ballgame
      • mydog2
        dude-x, -- um.. no.. it's not!
      • dude-x
        latest version also of python client was patched to fix some issues
      • lucast
        if you have a reproducible test case we can look at it, otherwise there's not much that can be done
      • mydog2
        i've generated a fresh centos install over the last few days. with google-chrome-stable v59 for the --headless feature -- no Xvfb
      • dude-x
        what's not being cleaned up chromedriver or Chrome?
      • smccarthy-sl joined the channel
      • mydog2
        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
      • dude-x
        are you running the script locally?
      • WhereIsMySpoon joined the channel
      • mydog2 i suspect....
      • mydog2
        yeah...
      • dude-x
        that driver.close() may be causing issues
      • remove it
      • mydog2
        and this is killing me.. as i don't have a full grasp
      • dude-x
        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
      • lucast
        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 &`
      • dude-x
        nope he just defines chromeoptions
      • mydog2
        lucast, -- no... i start google-chrome-stable
      • lucast
        why?
      • mydog2
        google-chrome-stable --headless --disable-gpu --remote-debugging-port=9222 http://localhost &
      • lucast
        chromedriver handles that for you
      • mydog2
        lucast.. i've cobbled all of this from different articles/testing..
      • dude-x
        lots of misinformation on the web
      • lucast
        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
      • mydog2
        which is why i ask questions here!
      • dude-x
        i've never manually started a chromedriver
      • lucast
        you only need to manually start it if you're wanting to use it as a remote endpoint
      • dude-x
        only time i write 'chromedriver' in the terminal is to just check that the PATH is correct
      • lucast
        ^
      • certainly never start chrome itself
      • dude-x
        lucast you mean indepdent of selenium standalone server?
      • lucast
        yeah
      • mydog2
        so.. should i just not start chrome.. as well as as chromedriver.. just assume that the test will fire it off?
      • dude-x
        yeah you can do that too, but i guess only if you have a need for something barebones.
      • lucast
        using 'http://127.0.0.1:9515' as the remote end
      • dude-x
        mydog2 yes.
      • mydog2
        ok.. i'll retest doing that..
      • lucast
        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
      • mydog2
        my goal.. to be able to have multiple simultaneous clients firing off test urls..
      • dude-x
        killall chromedriver
      • lucast
        you can do that
      • dude-x
        yes you can do that. multiple processes will each have their own chromedriver, and instance of chrome
      • mydog2
        as fast as possible.. unfortunately.. the target url is/are dynamic script.. so sel+py+chrome is more or less required
      • lucast
        or you could use one chromedriver with a bunch of remote driver instances talking to it... but lets not get into that
      • mikey_ joined the channel
      • dude-x
        let's keep it simple
      • lucast how would you tell the python client not to kill chromedriver?
      • WhereIsMySpoon
        dont call driver.quit?
      • kpschmidt joined the channel
      • nku
        hm, how can i turn down the loglevel= -debug false stills print info messages i don't want
      • ?
      • mydog2
        rerunning to setup the test... takes a bit
      • so.. if i get this working.. where do i send the oj?
      • dude-x
        OJ is free once more.
      • mydog2 send coconuts to NJ.
      • lucas-jones-sl
        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
      • dude-x
        lucas-jones-sl is the element... an image?
      • lucast
        dude-x: i was going back to starting chromedriver separately and using remote
      • kpschmidt
        What is the purpose/meaning of "enablePassThrough"?
      • WhereIsMySpoon
        lucas-jones-sl: what is ‘visually displayed'?
      • fatguylaughing has quit
      • lucas-jones-sl
        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
      • WhereIsMySpoon
        lucas-jones-sl: that’s presence, then
      • as in, present in the DOM
      • and that doesnt mean its visually displayed
      • dude-x
        presence is the element exists in the DOM
      • like many divs that impart structure
      • WE1LS
        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
      • WhereIsMySpoon
        i feel another factlet needing to be added
      • WE1LS: we can’t possibly know, we aren’t xpath parsers. Try it and see
      • jimpurbrick1 has quit
      • jimpurbrick joined the channel
      • WE1LS
        i already use this xpath segment. it is how i make sure an element is in the DOM and also visible
      • WhereIsMySpoon
        WE1LS: oh, I see. In that case, your xpath doesn’t cover even half the things that affect visibility
      • lucast
        and afaik those are all covered by the driver's way of determining
      • WhereIsMySpoon
        yep
      • dude-x
        selenium visibility check has many checks
      • jimpurbrick has quit
      • selbot2-commits
        [13selbot2] 15Jarob22 opened pull request #60: try it and see factlet (06master...06try-it-and-see) 02https://git.io/v7U9N
      • fatguylaughing joined the channel
      • lucas-jones-sl
        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?"