New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 680290 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 3
Type: Bug



Sign in to add a comment

There should be a way to make EarlGrey ignore animations

Project Member Reported by eugene...@chromium.org, Jan 11 2017

Issue description

Earl Grey does not tap on dialog buttons when loading spinner animation is active:

Reason: Action 'Tap' failed.
Element matcher: (((respondsToSelector(isAccessibilityElement) && isAccessibilityElement) && accessibilityLabel("Cancel")) && ((respondsToSelector(isAccessibilityElement) && isAccessibilityElement) && accessibilityTraits: UIAccessibilityTraitButton))
Complete Error: Error Domain=com.google.earlgrey.ElementInteractionErrorDomain Code=3 "Failed to execute action within 30 seconds." UserInfo={NSLocalizedDescription=Failed to execute action within 30 seconds., NSUnderlyingError=0x618000857d60 {Error Domain=com.google.earlgrey.GREYUIThreadExecutorErrorDomain Code=0 "Failed to execute block because the following IdlingResources are busy: ['GREYAppStateTracker']
Busy resource description:
  GREYAppStateTracker : Waiting for CAAnimations to finish. Continuous animations may never finish and must be stop explicitly. Animations attached to hidden view may still be executing in the background.


This can be reproduced by running HTTPAuthTestCase on iPad.

 

Comment 1 by baxley@chromium.org, Jan 13 2017

I talked to Sundeep and they don't have a great solution for this. Someone tried to solve it, but they encountered flake issues.

Currently we have aren't blocked by disabling synchronization, but I think it's reasonable to keep this as P3.
Project Member

Comment 2 by sheriffbot@chromium.org, Feb 15 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: -baxley@chromium.org huangml@chromium.org liaoyuke@chromium.org linds...@chromium.org
Owner: eugene...@chromium.org
Status: Assigned (was: Untriaged)
Eugene, have you tried disabling EG synchronization for that test and using WSO callbacks to gate on navigation events?  That worked for a similar issue I ran into writing an EGTest for JS onload events since the activity indicator spun indefinitely until the dialog was dismissed. Example CL: https://codereview.chromium.org/2825673003

If that's not the case, feel free to reassign.  I'm not sure who should be handling this type of issue now that baxley is gone, though.
Cc: eugene...@chromium.org
Owner: ----
Status: Untriaged (was: Assigned)
kGREYConfigKeySynchronizationEnabled does not always work (like in case with HTTPAuthTestCase on iPad). I'm not the right owner for EG framework bugs. Yuke, Menglu, who would be the right owner here?
Status: Available (was: Untriaged)
This seems to be EarlGrey bugs.  I don't think they're still working on it.  Marking it as available.
Since we have the workaround to disable synchronization,  maybe we should close the bug?
We do not have a workaround. kGREYConfigKeySynchronizationEnabled does not work for HTTPAuthTestCase.
How many tests are affected by this issue? As far as I know, the EarlGrey team is fully committed to releasing EarlGrey 2 right now, so if it's a framework bug, it's very unlikely they can get to it any time soon, would it be reasonable to revisit this issue after switching to eg2?
A lot of test have to use ugly kGREYConfigKeySynchronizationEnabled. kGREYConfigKeySynchronizationEnabled does not work only for HTTPAuthTestCase suite. 

What is the synchronization model for EG2? Same as for EG1? Wait for all CoreAnimation activities to complete?
Yes, it will be the same as EG1. Per comment #1: "Someone tried to solve it, but they encountered flake issues.", it looks like there was a solution, but didn't work due to flakiness issues.

One big selling point of EG2 is that it will be less flaky than EG1, so hopefully, this  won't be an issue in EG2.

Sign in to add a comment