Closed Bug 1007510 Opened 11 years ago Closed 11 years ago

Intermittent failing test, test_a11y_unlock_to_homescreen.py test_a11y_unlock_to_homescreen.TestLockScreenAccessibility.test_a11y_unlock_to_homescreen

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::System::Window Mgmt
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kgrandon, Assigned: alive)

References

Details

Attachments

(2 files)

window management log
18.70 KB, text/plain
Details
https://github.com/mozilla-b2g/gaia/pull/19352
46 bytes, text/x-github-pull-request
timdream
: review+
Details | Review
We are seeing this on travis fairly frequently now.. TEST-START test_a11y_unlock_to_homescreen.py test_a11y_unlock_to_homescreen (test_a11y_unlock_to_homescreen.TestLockScreenAccessibility) ... ERROR ====================================================================== ERROR: None ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/mozilla-b2g/gaia/travis_venv/local/lib/python2.7/site-packages/marionette_client-0.7.7-py2.7.egg/marionette/marionette_test.py", line 163, in run testMethod() File "/home/travis/build/mozilla-b2g/gaia/tests/python/gaia-ui-tests/gaiatest/tests/accessibility/lockscreen/test_a11y_unlock_to_homescreen.py", line 23, in test_a11y_unlock_to_homescreen self.wait_for_condition(lambda m: self.accessibility.is_hidden(homescreen_container)) File "/home/travis/build/mozilla-b2g/gaia/tests/python/gaia-ui-tests/gaiatest/gaia_test.py", line 1085, in wait_for_condition Wait(self.marionette, timeout).until(method, message=message) File "/home/travis/build/mozilla-b2g/gaia/travis_venv/local/lib/python2.7/site-packages/marionette_client-0.7.7-py2.7.egg/marionette/wait.py", line 143, in until cause=last_exc) TimeoutException: TimeoutException: Timed out after 10.0 seconds TEST-UNEXPECTED-FAIL | test_a11y_unlock_to_homescreen.py test_a11y_unlock_to_homescreen.TestLockScreenAccessibility.test_a11y_unlock_to_homescreen | ---------------------------------------------------------------------- Ran 1 test in 20.710s FAILED (errors=1)
Eitan, yzen, ni?
Flags: needinfo?(yzenevich)
Flags: needinfo?(eitan)
This is looks like a legitimate bug, not a test problem. This was supposedly fixed in bug 985037, but seems to have regressed.
Blocks: 985037
Flags: needinfo?(timdream)
Flags: needinfo?(eitan)
Flags: needinfo?(alive)
Flags: needinfo?(yzenevich)
Attached file window management log —
From gecko.log, I could see that both the homescreen and lockscreen have aria-hidden=false, this should never be the case.
I am not familiar with this code.
Flags: needinfo?(timdream)
Log: FTU closed and some one opens lockscreen + homescreen at the same time which causes this issue. I will fix it.
Assignee: nobody → alive
Component: Gaia::UI Tests → Gaia::System::Window Mgmt
Flags: needinfo?(alive)
Exactly..I cannot reproduce. I don't see lockscreen window is created during FTU. Eitan could you help to do some debugging in https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/lockscreen_window_manager.js#L299?
Flags: needinfo?(eitan)
Also if you'd like I could mentor you to fix this one if I cannot reproduce in my side anyway.
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7) > Exactly..I cannot reproduce. I don't see lockscreen window is created during > FTU. Eitan could you help to do some debugging in > https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/ > lockscreen_window_manager.js#L299? What specifically would you like from that line? A stack trace? lwm_createWindow@app://system.gaiamobile.org/js/lockscreen_window_manager.js:299:11 lwm_openApp@app://system.gaiamobile.org/js/lockscreen_window_manager.js:244:9 lwm_initWindow/req.onsuccess@app://system.gaiamobile.org/js/lockscreen_window_manager.js:325:9 I could reliably reproduce it. I do the following: 1. rm -rf profile 2. tests/travis_ci/gaia_ui_tests/install 3. I edit tests/travis_ci/gaia_ui_tests/script to run $root/tests/accessibility/lockscreen/test_a11y_unlock_to_homescreen.py 4. tests/travis_ci/gaia_ui_tests/script .. and it fails.
Flags: needinfo?(eitan)
Alive, friendly ping? See eeejay's comment #9. Can we move this forward and get the lock screen test re-enabled?
Flags: needinfo?(alive)
(In reply to Eitan Isaacson [:eeejay] from comment #9) > (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7) > > Exactly..I cannot reproduce. I don't see lockscreen window is created during > > FTU. Eitan could you help to do some debugging in > > https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/ > > lockscreen_window_manager.js#L299? > > What specifically would you like from that line? A stack trace? > lwm_createWindow@app://system.gaiamobile.org/js/lockscreen_window_manager.js: > 299:11 > lwm_openApp@app://system.gaiamobile.org/js/lockscreen_window_manager.js:244:9 > lwm_initWindow/req.onsuccess@app://system.gaiamobile.org/js/ > lockscreen_window_manager.js:325:9 > > I could reliably reproduce it. I do the following: > 1. rm -rf profile > 2. tests/travis_ci/gaia_ui_tests/install > 3. I edit tests/travis_ci/gaia_ui_tests/script to run > $root/tests/accessibility/lockscreen/test_a11y_unlock_to_homescreen.py > 4. tests/travis_ci/gaia_ui_tests/script > > .. and it fails. Do you repro this on real device? I cannot repro it, lockscreen is not created during ftu.
Flags: needinfo?(alive)
OK, I reproed in desktop. patch coming.
Launch homescreen at background to avoid having two foreground app during FTU
Attachment #8424454 - Flags: review?(timdream)
Comment on attachment 8424454 [details] [review] https://github.com/mozilla-b2g/gaia/pull/19352 I wonder if this is the correct approach -- do we always launch homescreen as background frame? What if home screen crashes on foreground?
Attachment #8424454 - Flags: review?(timdream) → review+
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #14) > Comment on attachment 8424454 [details] [review] > https://github.com/mozilla-b2g/gaia/pull/19352 > > I wonder if this is the correct approach -- do we always launch homescreen > as background frame? What if home screen crashes on foreground? AppTransitionController will always send it to foreground if open is proceeded -- and since crash trigger reopen process, in the long run it got visible.
https://github.com/mozilla-b2g/gaia/pull/19352
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
This seems to be failing on TBPL on OSX: https://tbpl.mozilla.org/?tree=Gaia-Try&rev=ee4e6b6be83c Should this but be reopened?
Flags: needinfo?(alive)
Uh..but it works in travis. Could we turn off that in tbpl only and open another bug to track?
Flags: needinfo?(alive)
(In reply to Yura Zenevich [:yzen] from comment #18) > This seems to be failing on TBPL on OSX: > https://tbpl.mozilla.org/?tree=Gaia-Try&rev=ee4e6b6be83c > Should this but be reopened? But why I don't see the failure in recent pull requests? https://tbpl.mozilla.org/?tree=Gaia-Try
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #20) > (In reply to Yura Zenevich [:yzen] from comment #18) > > This seems to be failing on TBPL on OSX: > > https://tbpl.mozilla.org/?tree=Gaia-Try&rev=ee4e6b6be83c > > Should this but be reopened? > > But why I don't see the failure in recent pull requests? > https://tbpl.mozilla.org/?tree=Gaia-Try Ya I am in the middle of adding the a11y tests to TBPL (not yet there officially - bug 1010746).
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #19) > Uh..but it works in travis. Could we turn off that in tbpl only and open > another bug to track? Ok ill disabled for osx and open a new bug.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: