Closed Bug 862053 Opened 7 years ago Closed 7 years ago

Can't send_keys to a visible input element

Categories

(Testing :: Marionette, defect)

Other
Gonk (Firefox OS)
defect
Not set

Tracking

(firefox23 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

RESOLVED FIXED
mozilla23
Tracking Status
firefox23 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: zcampbell, Assigned: jgriffin)

References

Details

Attachments

(2 files)

Attached file test case
Can't send_keys to a input element.

The element is visible on the screen and is_displayed() returns "True" for the element but it is interpreted as not visible when the send_keys command is performed on it.

This is on b2g18 and v1train and would seem to be a direct result of the uplift in 830197.

Build: 20130415070205
Gaia commit: baec473de45
OS: Windows 7 → Gonk (Firefox OS)
Hardware: x86_64 → Other
I have been working on test_add_new_contact, which is suffering from this as well. I was experimenting with removing some of the typing as some fields seem to consistently work and others do not. On one of my last tests I noticed this stack trace: [1] 

I don't know if the order in which the statements are displayed reflects the actual execution of the test, but even if not, it is surprising to see that [2] happened at all considering that [3] generated an exception.

To me it looks like things are happening asynchronously, and commands that appear earlier in the test [4] are being executed after commands that appear later [5].

If that is in fact happening, might that explain why Marionette is reporting some elements as not displayed when we expect them to be?

[1] https://gist.github.com/bobsilverberg/5393067
[2] https://gist.github.com/bobsilverberg/5393067#file-gistfile1-txt-L11
[3] https://gist.github.com/bobsilverberg/5393067#file-gistfile1-txt-L13
[4] https://github.com/mozilla/gaia-ui-tests/blob/master/gaiatest/tests/contacts/test_add_new_contact.py#L37
[5] https://github.com/mozilla/gaia-ui-tests/blob/master/gaiatest/tests/contacts/test_add_new_contact.py#L42
I don't understand the stack trace in [1] at all; it doesn't seem like it should be possible.  Is that occurring with the version of test_add_new_contact.py that's in the gaia-ui-tests repo?

One way to debug this would be to run it through pdb so you can see what's happening during that test.
Zac, I couldn't reproduce this locally.  But, your test snippet includes an element id 'icon-add' which doesn't appear in the Contacts app (on mozilla-b2g18), so I replaced it with 'add-contact-button', and the locator 'receiver-input' doesn't exist either, so I replaced it with 'org'.   When I do that, the test works ok.

So I'm probably missing something about the environment this test was run in.  Can you attach an entire test file that reproduces this, in case something in setUp is helping this problem to manifest?
I can reproduce this now.  For some reason we seem to be scrolling the input element (which is already visible and shouldn't be scrolled), and after that we can't find it any longer.

I'll try to debug what's happening.
The discrepancy occurs because is_displayed() just checks to see if an element is displayed, while send_keys (and other manipulative methods) do that, plus try to scroll the element into view if it isn't in the viewport.

There seems to be a bug in elementInViewport, I'll track it down.
Assignee: nobody → jgriffin
This was CSS transforms biting us again.  One of the parents of the element in question was CSS transformed, and that let to incorrect offsetX/Y values.

Using getClientBoundingRect instead of a chain of offsetParents avoids this issue.
Attachment #738120 - Flags: review?(mdas)
Attachment #738120 - Flags: review?(mdas) → review+
https://hg.mozilla.org/mozilla-central/rev/84f1beec31da
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.