Closed Bug 847655 Opened 11 years ago Closed 11 years ago

Can neither tap nor click on the Marketplace sign-in button

Categories

(Remote Protocol :: Marionette, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

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: bsilverberg, Assigned: automatedtester)

References

Details

Attachments

(2 files, 1 obsolete file)

In a gaia-ui-test, after navigating to the settings page of marketplace, calling either tap() or click() on the sign in button do not cause the button to be clicked. I can see visually that tap does nothing, while click does cause the button to appear depressed, but in neither case is the Persona frame loaded into the trusted-ui container as expected.

I verified this by adding a sleep at the appropriate stage of the test and clicking the sign in button manually, which did load the Persona frame and allowed the test to complete successfully.

I have attached a reduced gaia-ui test case which illustrates the issue.
I also seem to be unable to either click or tap on the "This session only" button during the Persona login workflow, which is also blocking automation of the Marketplace login.
:jedp could this be related to bug 822964
We really need this in order to flesh out our Marketplace tests (currently, limited to the signed-out tests, which are few).

A-team, do you have the cycles to/can you make this a high priority?  Thanks!
Severity: normal → critical
This sounds a lot like https://bugzilla.mozilla.org/show_bug.cgi?id=833061, I'll investigate this further tomorrow
So the selector has changed, it should now be:
_sign_in_button_locator = ('class name', 'full button alt browserid')

Also, I can't seem to get past the sign-in button, even manually.

Despite that, I'm seeing some interesting behaviour. If you use click(), the button appears to be depressed, and activates the spinner, but the button doesn't appear to be released. Now, if we use tap(), the button doesn't appear to get depressed, but it does get activated (you'll see a spinner next to it, and it gets cut off by the edge of the phone).  

I thought at first it's because tap() is sending only touch events, but that is not the case. Since this isn't a gaia app (it's an external app), and doesn't use the mouse event shim, then we send touch/mouse/click events. 

If we use b.single_tap() which should just send the touch events (no mouse events), the button gets depressed, but no spinner shows up.

Following this logic, I modified tap() so it will only send touch events. This should be exactly the same as single_tap, but in this case, nothing happened on the screen. This means that tap() is deviating from our expectations, which makes sense since tap() is currently generated using synthetic_gestures.js library, and we're moving away from that. 

We will be reimplementing tap() shortly, and when Bug 850819 lands, we can then just use single_tap() to do what tap does for us. We'll then update the python abstract layer to use our new methods (Bug 845849)

In the meantime, can you use either click() or tap() for this test? They appear to at least activate the button so you should be able to continue writing the test.
Bah, using today's build, I can finally tap the Sign In button manually and get a new card view, but not with marionette. Will investigate further.
fyi, i'll try to ping the marketplace devs (kumar?) and see what this particular button expects.
potch pointed out that launching popups is protected by accepting trusted events only. Ie, a button that launches a popup (in this case, the persona card) requires the incoming event to be a trusted event. Marionette only generates untrusted events at the moment.

To automate this, we'll need to figure out how to generate trusted events. I'll catch up with AutomatedTester tomorrow, I know he looked into this briefly.
(In reply to Malini Das [:mdas] from comment #8)
> potch pointed out that launching popups is protected by accepting trusted
> events only. 

It would be super-helpful if marionette were able to generate native events.  (There's already Bug 821740 for it.)

The way we're getting around this for identity testing is to set a pref that tells our code that events don't have to be native: dom.identity.syntheticEventsOk (See Bug 821740)
Curiously, I ran my branch of gaia-ui-tests which was failing on the Marketplace sign-in button after adding dom.identity.syntheticEventsOk but it still failed to launch Persona.

For sanity, we should probably try getting tap to work for the simplest possible case like this to make sure we're solving the right problem:

<button onclick="navigator.id.request()">sign in</button>
I don't know that dom.identity.syntheticEventsOk is going to be a panacea; you may be interacting with other APIs that require non-synthetic events?

http://mxr.mozilla.org/mozilla-central/search?string=isHandlingUserInput

But overall, I'm having a similar, really basic problem - i can launch the UI Tests app, but i seem to be unable to click on the "navigator.mozId tests" item from an automated test, though I can drive marionette to click on it in the python repl.  Working on isolating the issue.
Attachment #720930 - Attachment mime type: text/x-python → text/plain
Looking through all the code we dont have the ability to send trusted events via widgets to mobile versions of Firefox since nsiDOMWindowUtils.sendNative*Events havent been ported to those environments
Ok I have got this working with a click() using the EventUtils approach. I need to now try update them to the latest version and use the touch.
This is awesome, David.  I'll test this asap!
after rejigging I cant seem to get touch to work for this for tap however I can get this to work for click().

I am going to have to redo some of the click logic so we know where to kick properly.
going to rip out the Atoms and replace it with better uses of EventUtils with the click() algorithm from Selenium.

Good thing we are writing a spec for this!
Assignee: nobody → dburns
Blocks: 839301
Noticed my playing went a long with patches, resubmitted 

https://tbpl.mozilla.org/?tree=Try&rev=006c6a4de6e5
try is green \o/

Want to test with GaiaTest before submitting patch
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Comment on attachment 730727 [details] [diff] [review]
remove atoms and use eventutils for trusted events

Review of attachment 730727 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #730727 - Flags: review?(jgriffin) → review+
https://hg.mozilla.org/mozilla-central/rev/56fe7e26fa47
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Thanks to everyone on the ateam for this fix. I am now able to click (but not tap) on the Sign In button in Marketplace which is great! I am able to get through the entire login sequence with marionette, but, unfortunately I am not able to click nor tap on the Sign Out button after logging in.

I am attaching the test case which demonstrates this.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is the test case that successfully logs in to Marketplace but cannot click nor tap on the Sign Out button.
Attachment #720930 - Attachment is obsolete: true
Will leave it up to the A-team, but comment 26 and comment 27 might warrant their own bug (thought you do mention it's the same window, etc.)
I verify that the login works. Haven't looked closely at the logout yet.

Amazing work, thanks AutomatedTester, mdas, jgriffin and all involved!
:bsilverberg

Can you please raise a separate bug for your issue and assign it to me and I will look at it ASAP!
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Blocks: 857717
Done. Bug 857717. Thanks AutomatedTester
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: