Closed Bug 1007510 Opened 10 years ago Closed 10 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: 10 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: