Closed Bug 862156 Opened 7 years ago Closed 5 years ago

Marionette thinks that the play button in the music app is not displayed

Categories

(Testing :: Marionette, defect, P1, major)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bsilverberg, Assigned: automatedtester)

References

Details

(Whiteboard: [displayed][affects=b2g])

Attachments

(1 file)

I apologize if a bug has already been opened for this, as there is a comment in the code for the test suggesting that this is a known bug, but I cannot find it.

In our test for the music player, the play button is reported as not displayed even though it is displayed. This prevents us from waiting for it to be displayed, and also prevents marionette from tapping on it even if we introduce our own wait via sleep().

The attached test case from our repo demonstrates the issue.
Blocks: 801898
It might be the same issue in Bug 814037 but not sure...
(In reply to Florin Strugariu [:Bebe] from comment #2)
> It might be the same issue in Bug 814037 but not sure...

Not sure; this test is xfailed, now, but is still failing.  If bug 814037 is indeed fixed, it's something else, then.
Severity: normal → major
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Blocks: 865232
lets have a gander
Assignee: nobody → dburns
Whiteboard: [xfail]
According to jsmith, this is blocking a significant chunk of automation.  David, do you have time to investigate this?  If you don't, Malini may be able to pick it up.
Flags: needinfo?(dburns)
Specifically, this blocks running a sanity test to playback a mp3 file in the music app on device. Not having this will block the ability to also expand coverage for playback of any additional mime types in the Music app as well (e.g. ogg, opus).
(In reply to Jonathan Griffin (:jgriffin) from comment #5)
> According to jsmith, this is blocking a significant chunk of automation. 
> David, do you have time to investigate this?  If you don't, Malini may be
> able to pick it up.

I am investigating this but as I said in my email to Jason its not a trivial fix.
Flags: needinfo?(dburns)
(In reply to Jason Smith [:jsmith] from comment #6)
> Specifically, this blocks running a sanity test to playback a mp3 file in
> the music app on device. Not having this will block the ability to also
> expand coverage for playback of any additional mime types in the Music app
> as well (e.g. ogg, opus).

If you are just wanting to check that mime types play you can execute the JS that the button executes since changes to the app could make your test flaky. 

If you are testing that the play button works like a user would, which is what I am investigating, then checking it working is the correct thing to do.
The other option is to ask Dominic to change the HTML/CSS into testable HTML.

David can you describe the problem in here to Dominic?

He and the media team have asked in the past about our app coverage and we have good coverage for all of the Media team's app except for the Music app. Like Jason I would love to be able to increase the on-device coverage of it.
I think the issue is that there is an issue with the way Marionette is interpretting the overflow that is on element with id views-sublist. Below is a snippet of the debug on this


(Pdb) pl = m.find_element(*self._views_sublist_controls_play_locator)
(Pdb) pl.is_displayed()
False
(Pdb) pl.get_attribute('style')
u''
(Pdb) pl.get_attribute('visibility')
(Pdb) pl.value_of_css_property('visibility')
u'visible'
(Pdb) ppl = m.execute_script('return arguments[0].parentNode', [pl])
(Pdb) ppl.value_of_css_property('visibility')
u'visible'
(Pdb) ppl.value_of_css_property('overflow')
u'visible'
(Pdb) ppl.get_attribute("id")
u'views-sublist-header-controls'
(Pdb) pppl = m.execute_script('return arguments[0].parentNode', [ppl])
(Pdb) ppl.get_attribute("id")
u'views-sublist-header-controls'
(Pdb) pppl.value_of_css_property('overflow')
u'visible'
(Pdb) pppl.value_of_css_property('visibility')
u'visible'
(Pdb) ppppl = m.execute_script('return arguments[0].parentNode', [pppl])
(Pdb) ppppl.value_of_css_property('overflow')
u'hidden'
(Pdb) ppppl.get_attribute("id")
u'views-sublist'
Depends on: 938242
Dominic, is there any chance of getting the markup for the music app changed to allow for us to unblock this automation?
Flags: needinfo?(dkuo)
If we cannot get the markup fixed then we have a couple of options:

1. dburns is looking at fixing bug 938242, which may unblock this.
2. Use JS to start playing.

I will take care of #2 if need be, but only after bug 921514 has been merged.
Depends on: 921514
Flags: needinfo?(bob.silverberg)
(In reply to Bob Silverberg [:bsilverberg] from comment #11)
> Dominic, is there any chance of getting the markup for the music app changed
> to allow for us to unblock this automation?

Bob, thanks for asking this, and I think I should be able to work on this since it has blocked you guys for a while, let me find out what's the root cause first and I am leaving the needinfo to remind myself.
Thanks Dominic, that's great. It will be nice to be able to get some automation happening for the music app again!
Now that bug 938242 has landed in m-c, I will try tomorrow's build using actions again. It still would be best if we could just tap, though.
Ok, I managed to interact with the music app using Marionette Actions, after the landing of bug 938242. Hooray! I'm going to update the music app, after bug 921514 lands, to enable that test.
Flags: needinfo?(bob.silverberg)
cool!
Whiteboard: [xfail]
Blocks: 984663
It sounds like the play button now works, what's left to do here? I'd like to close this bug.
I just checked and this specific case as per the subject and comment #0 is still valid.

We worked around it to keep the test coverage alive, but the initial bug is valid.
There's already a known way to workaround this problem, so this shouldn't be a test blocker here for CS testing. If you need information on how to do this, then feel free to followup with the folks on this bug.
No longer blocks: 984663
(In reply to Jason Smith [:jsmith] from comment #20)
> There's already a known way to workaround this problem, so this shouldn't be
> a test blocker here for CS testing. If you need information on how to do
> this, then feel free to followup with the folks on this bug.

Vasanth, can you please check on this further
Flags: needinfo?(vasanth)
MP3 playback works for me in latest build. Thanks
Flags: needinfo?(vasanth)
Whiteboard: [displayed]
Priority: -- → P3
Priority: P3 → P1
This is blocking tests, so I bumped to P1
Whiteboard: [displayed] → [displayed][affects=webqa]
Flags: needinfo?(dkuo)
Whiteboard: [displayed][affects=webqa] → [displayed][affects=b2g]
This is working for me. Please reopen with a new sample test case if you can still reproduce it.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
(In reply to Dave Hunt (:davehunt) from comment #24)
> This is working for me. Please reopen with a new sample test case if you can
> still reproduce it.

Because a workaround was checked in for this:
http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/music/regions/sublist_view.py#25
(In reply to Martijn Wargers [:mwargers] (QA) from comment #25)
> (In reply to Dave Hunt (:davehunt) from comment #24)
> > This is working for me. Please reopen with a new sample test case if you can
> > still reproduce it.
> 
> Because a workaround was checked in for this:
> http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/
> music/regions/sublist_view.py#25

I didn't use the test from the repository, I used the sample test attached to this bug, which does not use a workaround. Note that my comment was almost a year ago now, so there's a very good chance it's out of date.
Oh, ok, I guess the workaround could be removed then.
You need to log in before you can comment on or make changes to this bug.