1008961 - Bookmark delete confirmation does not immediately popup after initial delete

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[[:AndreiH]]

Our automated test that deletes and app from the Homescreen is intermittently failing on the Desktop build when trying to tap on the "Delete" button.

Sometimes the test taps on the button before that button is functional/loaded.

Element is visible but may not be manipulated, test moving to fast.
We tried waiting for other elements from the confirmation menu, but that didn't help.

Here is the portion of HTML from the confirmation menu:
https://gist.github.com/AndreiH/13bde3b584526e15e951

The test that fails on Travis:
https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/gaiatest/tests/functional/homescreen/test_homescreen_delete_app.py

Comment 1

[[:AndreiH]]

What can happen, and is possibly happening in this case, is that the delete button is visible but still moving or not functional. So marionette takes it as visible, as soon as it is visible and then aims a tap there. However after marionette calculates but before it taps, the element is still disabled.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I noticed that I had some timing issues when doing : 
homescreen.bookmark(self.bookmark_title).tap_delete_app().tap_confirm(bookmark=True)

It would try to tap_confirm before tap_delete_app().  I resolved it by doing a : 
homescreen.bookmark(self.bookmark_title).tap_delete_app()
homescreen.bookmark(self.bookmark_title).tap_delete_app().tap_confirm(bookmark=True)

I don't like doing this much; because it causes an extra bit of searching/finding.  Having said that, there's no need to have a 1 sec delay in apps.homescreen.regions.confirm_dialog.py

I no longer get intermittent failures when I ensure I tap the delete app before calling the tap_confirm.

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hey guys, I ran into this bug.  I was wondering what your input might be.

Comment 4

[Martijn Wargers (dead)]

I had this same issue while testing the patch in bug 926881, see bug 926881, comment 12 and further. For me, it was reproducible with that test. After updating my tree, it didn't happen anymore.
That being said, I can surely believe this issue is still lurking around, it seems timing dependent.

I guess what you do here can solve your issue, but it would be better if we could solve this in a more generic way.
I don't see much harm to add a time.sleep(.1) or something, in tap_confirm() if there is no better way of solving this.

Comment 5

[Johan Lorenzo [:jlorenzo]]

To me, this is an actual bug in the Homescreen. I repro'd the issue manually on a Flame. 

STR
1. Tap the delete icon of a bookmark
2. Cancel the operation on the confirmation window.
3. In less than half a second tap the delete icon again.

Actual result
On my flame, the confirmation window didn't show up. I managed to tap it up to 3 times. Sometimes after starting up the phone, it happens. This could explain why it has been filed as an intermittent. See the last 2 tries in this video: http://mzl.la/1Ads4CH.
I checked with the debugger enabled, and it seems that handleEvent[1] is never called during step 3. Kevin, do you have an idea of what could be the cause? 

Repro frequency: 5/5 (if you don't try to tap multiple times like I did in the video ;) )

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/verticalhome/js/app_manager.js#L58

Comment 6

[Kevin Grandon :kgrandon]

This bug confuses be because it seems it was originally not filed as part of the vertical home screen. I'm not really sure what the loaded class will achieve, so going to re-title this to reflect the findings in comment 5. Will investigate as time permits, leaving the ni for now.

Comment 7

[Kevin Grandon :kgrandon]

It seems that the cause of this is bug 1055299, which tries to hack the home screen to ignore multiple app launch requests. I think we need to move that logic into the platform to properly fix it.

Comment 8

[GitHub Autolander Bot]

Attachment: [PullReq] KevinGrandon:bug_1008961_remove_continuous_app_workaround to mozilla-b2g:master

Comment 9

[Kevin Grandon :kgrandon]

Here's a pull request which removes the previous workaround we had. Like I said in bug 1055299 comment 107 I don't believe this is the correct fix. We need the system app to handle multiple app launches gracefully with third party home screens.

Comment 10

[Kevin Grandon :kgrandon]

Mass update: Resolve wontfix all issues with legacy homescreens.

As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.