#selenium

no worries. i'm making sure the branch is up-to-date and will run properly anyway.

Lovely. Thank you

jimevans: just sent an email to the w3c mailing list asking about how we'll manage the conformance suite.

thanks, lucast. How do I assert the existence of an element on a page?

like .is_displayed(), but just about the existence of such a node in DOM

well, if you aren't catching the error it raises already i'm assuming the test would fail

That was cutting it fine. The W3C WG has been extended to 30th September

so if .find_element() fails - the unittest stops and the script tearDowns?

i believe so, haven't used unittest in a while... you could try it

.find_element_by_css_selector('#spoons')

unless you're on some sort of cutlery website...

in that case i'd use a different selector

[13selenium] 15shs96c pushed 1 new commit to 06master: 02https://git.io/vSZju

13selenium/06master 14cd0b8b7 15Simon Stewart: Fix the build

The AuthenticatedPageLoadingTest doesn't seem to produce much value

it did at one point. the IE driver implemented the authentication end point.

but then microsoft changed the auth dialog, and i never updated it.

HI All, is mouse actions are fixed in 3.3.1? with latest gecko? I am using latest firefox as well. 52

rajeev-sl: are you having issues?

they are implemented, but there are still a couple bugs

jimevans: I don't suppose you have the logs from a test run with the w3c IE driver?

hi, Lucast, yes not working for me.

can you elaborate?

Used old way -

a.moveToElement(e).click(e).build().perform();

simonstewart: which logs do you mean?

The list of failing tests.

No capabilities are added @lucast

ah. indeed i do. i can give you the results xml...

Perfect. Thank you

rajeev-sl: does it give you an error?

No errors as well, just some logs with regards to js errors.. from Gecko logs

Thanks barancev

rajeev-sl: on a side note, click(e) would do the move itself, no need to move first

tried without moveto also

rajeev-sl: if there are no errors then you'd have to talk to mozilla

i see

simonstewart: do we need volunteers to develop tests for the spec? it is worth to make a public appeal?

Yes, and yes

I'll be making one at SeConf

so we need a landing page with contacts of a person

who will orchestrate this activity

It's like you read my mind

I read your message :)

I suspect the coordination will happen on the W3C #webdriver channel

Or in that spreadsheey

oh nice, didn't see the extension, woohoo

jimevans: it is expected that ie hangs on file upload dialogs?

barancev: no. it should not. if it does, i really need an IEDriverServer.exe log at TRACE level. people have been complaining about a bug there off and on for awhile, but i can never reproduce it.

I am stuck

ok, I'll rerun file upload test later, with TRACE log level

the main test suite is still running

'element = self.driver.find_element(By...., ...)' 'element.is_displayed()' - true, but 'element.click()' returns the error saying that the element is not clickable at point bla bla and that other element would receive the click.

if it is displayed, how it can't be clicked?

done

TESTS FAILED: 75 FAILURES

jimevans: ^^^

oooooooooooo try putting a time.sleep(2) before the click command. this is a simple test to see if you need to wait a bit.

dude-x: done, didn't work.

okay change the locator then

why?

it's obstructing the thing you're clicking on.

it what?

I'm finding element by ID, it is unique

it's blocking the element you're clicking on

doesn't matter

barancev: i have 49 failures. please make sure you're at the very latest on the branch (with AuthenticatedPageLoadingTest ignored for IE)

dude-x: so what should I do?

I'd understand it if something covered it

try an element that's higher than the thing you're clicking

but is_displayed = true for some reason (it should not be true)

it is displayed...

but I see that it is not

or is there something like .is_visible()?

is_dispalyed == true?

is_displayed is the visbility test

well, it fails

it says the element is visible, while it is not

oooooooooooo: youre not understanding what visibility is

just because something is covering it doesnt mean that it's not displayed

selenium doesnt use human beings to discern visibility

it checks some specific conditions

ah, so .is_displayed() just checks for presence in DOM tree + that the element is not disabled?

and that it isnt display: none and that its visibility: visible

and probably a few others

disabled has nothing to do with it afaik

there is .is_enabled()

oooooooooooo: and that it's in the view port, and that it's not of zero height and width, and that its css properties would cause it to be visible.

there you go ^

so there's no way to figure out if button is available for click?

heh

when you figure out, let everyone here know

there is WebDriverWait

so the answer is 'no'? do you have to play games with me?

the problem isn't that it's not displayed. the problem is that there's another element above it in the z-order at the location the driver is trying to click.

oh, really?

just because there's another element in the way doesn't mean the element you're looking for isn't "visible"

*at the location and time

I think it's that the element is just covered by another one

it just means you can't click on it directly.

just to be specific

so that I can't click it using cursor

like something is just over it

right

that's what the exception is telling you, yes.

yes, oooooooooooo

so that's what that error was about

jimevans: my test results https://gist.github.com/barancev/de214d63ac2296...

IE11, win64

simonstewart: should we suppose it's always true? https://github.com/SeleniumHQ/selenium/blob/mas...

what about htmlunit tests with "JS off"? disabling this mode?

barancev: looks like your results are substantially similar to mine, modulo the file selection dialog issues.

barancev: no

We can't assume it's always true

But what we can do is remove the method and reduce down to "is(JAVASCRIPT_ENABLED)"

It's going in 3.5