#selenium

an opinion*

second, someone may be wanting to do some task without the knowledge of the user of the machine. this is often (but not always) shady, but in either case, it's a mechanism that doesn't inform the user of the machine what's actually happening, and i tend to be opposed to that on philosophical grounds.

third, someone may want to spin off a process that won't interfere with their continued use of the machine. in this case there are often other, non-headless, options that are better suited to the task (like using a docker container in which to launch the browser)

finally, it occasionally boils down to "because i just want headless," in which case, i usually bow out of the conversation. until very recently, so-called "headless" browsers didn't live up to the promise, because none of them, not a single one, was the equivalent of using an actual browser that an end user would use.

there is a headless mode in an upcoming version of chrome, which, if it's *truly* equivalent to the normal version, *might* be fit for purpose of automating a page.

i believe the folks at mozilla are working on a similar mode for firefox.

i hasten to point out that neither of these modes for either browser is shipping in the stable channel of that particular browser yet.

jimevans: the news of the upcoming version of chrome sounds promising :)

i'm skeptical of its efficacy.

i'm willing to see, but i remain skeptical

in the betas, people have already run tests and found out there's only a negligible speed benefit

as jimevans said earlier, it's not the renderer that's making things slow :p

there. is. almost. no. perf. benefit. to. headless.

i don't know how to say it more plainly.

pretty much the only actual use case I can see for headless is the "I just want this task to run once an hour or so and not push a window up on my screen" problem, but there's other approaches there anyway (which jimevans also covered earlier)

Dritz: in fact, I do not care much about efficacy, but rather about reliability (so to reproduce everything like in the real-world browser such as Chrome, Firefox)

that said, if you want to literally run a ctrl+a ctrl+c command, I think you'll be out of luck for headless regardless, because that requires a visible window with focus to work.

the webdriver implementations are actually very reliable, in my experience

we have tests that run every couple of hours, and the small amount of flakiness we get is almost always from network slowdown server side

and the best part of webdriver is it's actually driving a real world browser, so it's one-to-one with what a user would see and experience; you don't quite get that from phantom :p

jimevans, Dritz: OK, the inquiry is now: Is it possible to employ "non-headless" browsers in kinda "detached" mode? (i.e. detach graphical interface, and communicate solely via API)

maybe you should try asking for what you're actually trying to accomplish instead of the technical details; for example, "can I run this without it popping up on my screen every time?", if that's what you're getting at

i'm out. i quit. i give up. i can't convince you that what you want is the Wrong Thing To Do™, so i'm not gonna try anymore.

there's often a better approach than the first thing that comes to mind :)

(and what you're asking for as a "detached mode" is functionally no different than the headless support that's still not quite there, and afaik doesn't exist as the question was posed)

Dritz: Yeah, in fact my interest is on the technical side. Here is an example of using 'driver.is_displayed()' with Selenium and PhantomJS (https://pastebin.com/RS4DKk0F). I am not yet sure whether it's equivalent to "visible text", and have to examine further...

I believe is_displayed checks if it's visible by CSS

from docs, "Is this element displayed or not? This method avoids the problem of having to parse an element's "style" attribute."

jimevans: Thanks. In fact, I am a newcomer, and I might not get all the nuances at this stage of my education in Selenium and related topics. Hope, it will change over time. Thanks!

I don't believe having a browser be headless or not will affect any part of Selenium, for what it's worth - we're really just talking about "does a browser window visibly open or not"

Dritz: thanks for the hint. I will perform further search towards that direction.

if you don't have any reason in particular to *not* have a browser window open, it won't matter to you either way

and keep in mind, it's not going to hijack an open browser or anything

WebDriver implementations generally open a new instance of the browser without any cookies or state from other sessions

so it's pretty well isolated

basically, I'd suggest you worry about getting a script that does what you want first, and if it still matters you to, then try to make it "headless" in whatever way you need

Well, what if one wish to open 10 or more browsers simultaneously? I am worried that I may get out of resources very soon with such approach. Am I wrong?

if you're using the real browser implementations, it won't be any different than running them headless

Maybe I am wrong, because I assume that "headless" browsers will consume much less resources (especially memory).

something like phantom may have less overhead just because it's incredibly minimalistic, but I doubt it'd be that much less, considering most of the overhead is from the loaded pages themselves

the only difference between headless and not is "does this get displayed on the screen", really

Dritz: OK, thanks for a clarification :)

performance impacts and resources required to display it are negligible

Happy to know that.

what takes a lot is loading all the elements on the page and executing the javascript, as well as actually contacting the server and downloading data

and that's not any different in headless mode :p

Cool :)

At least, I am not limited to PhantomJS...

jimevans: Could you recommend any basic setting with respect to dockerization, i.e. using browsers within docker containers? I had plan to ship scrappers with docker containers. Still, it's in the planning stage.

you'd probably want to do research into Selenium Grid; I believe the official containers are designed to make it easier to use Grid for remote / multiple browser testing

Dritz: OK, I will take a look. Many thanks once more.

basically your architecture for running tests is split into a Hub and one or more Nodes; test scripts contact the Hub with their browser requirements, and are directed to a Node. The containers are just pre-set up to work that way.

Definitely, I must have a look :)

Hello Everybody. It's possible bind a selenium webdriver to a internet interface?