850651 - [B2G] Action events/tap on statusbar element does not work

Status: RESOLVED WORKSFORME

(Remote Protocol :: Marionette, defect)

Description

[Zac C (:zac)]

Have tried numerous combinations of tap and action chains but cannot get this one to budge.

The test case is to tap or press on the statusbar to expand the notification bar.

-------------
statusbar = self.marionette.find_element('id', 'statusbar')
action = Actions(self.marionette)action.press(statusbar).wait(1000).move_by_offset(0, -400).release()
action.perform()
time.sleep(2)
        
# should be True
print self.marionette.execute_script("return window.wrappedJSObject.UtilityTray.shown")

Comment 1

[Malini Das [:mdas] - Away, not checking bugmail]

Attachment: runnable test case

Here's the test that you can run with gaiatest. It should pull down the notification tray, but it fails to do so.

Comment 2

[Malini Das [:mdas] - Away, not checking bugmail]

Yeesh. I think I know what's happening.

So, the action chains only dispatch touch events. Not mouse events. It seems, for *any* action like this in Gaia, you need to dispatch touch/mouse/click for any touchstart. We were working under the idea that only 'tap' (not drag, etc) events require this chain of events. We'll need to add mouse events into our action chains.

We're currently discussing how to do this, and I'll update this bug with the related bug when it gets created.

Comment 3

[Aaron Train [:aaronmt]]

Thanks for the update Malini. Thus far as far as I'm aware this seems to only block smoke-tests related to interactions with the status-bar in Gaia.

Comment 4

[Malini Das [:mdas] - Away, not checking bugmail]

I've created this bug for the discussion:
Bug 850819

Comment 5

[Malini Das [:mdas] - Away, not checking bugmail]

As an update, after talking with mbrubeck and cpeterson, and checking out the backend code, it looks like sending touch events only is the right thing to do in the case of a swipe gesture. 

That being said, I'm looking into the notifications tray's javascript and it expects either a mousedown event to trigger the tray expansion, or a 'swipe' event. 'swipe' isn't an official w3c touch event, it's a custom event fired by gaia's gesture detector. If you look at shared/js/gesture_detector.js, you can see the conditions under which the 'swipe' event gets fired.

Some new changes landed in the mozilla-b2g18 branch, so I'd like to test our action chains against it. If it still fails, then we still have options to get the notification tray/ We can either a) send a mousedown, b) send the exact touch gestured needed to trigger this 'swipe' gesture or c) generate the 'swipe' event ourselves.

Comment 6

[Zac C (:zac)]

Have tried a few combinations of the original test case and one that mdas gave me in IRC so far but with no luck of even getting it to budge. 

Curiously if I do a single_tap() on it it will 'pop out' but I can't get it to grab the id=utility-tray-grippy fast enough to start an action chain.

mdas, which element exactly receives the element, is it id=statusbar? It's the only one that's displayed so the only one I can perform the action on.

Is the system javascript in question in utility_tray.js?

Comment 7

[Malini Das [:mdas] - Away, not checking bugmail]

(In reply to Zac C (:zac) from comment #6)
> mdas, which element exactly receives the element, is it id=statusbar? It's
> the only one that's displayed so the only one I can perform the action on.
> 
> Is the system javascript in question in utility_tray.js?

That looks like it's the one, and onTouchStart, 'utility-tray' should be made available.

Considering the changes that have happened in tap, I took a look at this again. There is a little improvement, as you can now pop out the tray completely if you do an action.double_tap(statusbar).perform() on it.

As for dragging the bar, I attempted it like so:

statusbar = m.find_element('id', 'statusbar')
util = m.find_element('id', 'utility-tray-grippy')
action = Actions(m)
action.press(statusbar).wait(0.2).release().press(util).move_by_offset(0,50).release().perform()

but that doesn't drag the tray down. We may not be targeting the right elements though.

Comment 8

[Zac C (:zac)]

At some point this was resolved I know because we used actions on the status bar now as per https://bugzilla.mozilla.org/show_bug.cgi?id=1017567

Setting wfm.