Closed Bug 1008961 Opened 6 years ago Closed 4 years ago

Bookmark delete confirmation does not immediately popup after initial delete


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

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: AndreiH, Unassigned)




(1 file)

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:

The test that fails on Travis:
Blocks: 995019
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.
I noticed that I had some timing issues when doing : 

It would try to tap_confirm before tap_delete_app().  I resolved it by doing a : 

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

I no longer get intermittent failures when I ensure I tap the delete app before calling the tap_confirm.
Hey guys, I ran into this bug.  I was wondering what your input might be.
Flags: needinfo?(npark)
Flags: needinfo?(martijn.martijn)
Flags: needinfo?(jlorenzo)
Flags: needinfo?(gmealer)
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.
Flags: needinfo?(martijn.martijn)
To me, this is an actual bug in the Homescreen. I repro'd the issue manually on a Flame. 

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:
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 ;) )

Flags: needinfo?(npark)
Flags: needinfo?(kgrandon)
Flags: needinfo?(jlorenzo)
Flags: needinfo?(gmealer)
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.
Summary: [Desktop Build] Requesting a loaded class for the confirmation menu "Delete" button → Bookmark delete confirmation does not immediately popup after initial delete
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.
Blocks: 1055299
Flags: needinfo?(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.
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.
Blocks: 1231115
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.