1067649 - [Browser] With one window open in show windows view, dismissing it will leave browser in a blank white screen.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect)

Description

[[:RJ]]

Attachment: Whitescreenlog

Description:
With one window open in show windows view, dismissing it will leave browser in a blank white screen with no functionality and can only go back to home screen by hitting home or locking and then unlocking the phone.


Repro Steps:
1) Update a Flame to 20140915000203
2) Search a term in Rocket bar or in browser
3) Tap ellipsis in the top right of the browser > tap view windows 
4) With the single window in windows mode dismiss it by swiping up 


Actual:
Blank white screen with no functionality or way back to home screen on screen 


Expected:
Brought back to home screen 

Environmental Variables:
Device: Flame 2.1 (319mb)
Build ID: 20140915000203
Gaia: 944e5b4582c4efa1b67cd33245dbb8f6aa25d09f
Gecko: 7546fedad918
Version: 34.0a2
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro frequency:100%
See attached: logcat, video clip: https://www.youtube.com/watch?v=n33iR8m424k&feature=youtu.be,

Comment 1

[[:RJ]]

This issue DOES occur on Flame 2.1(512mb), Open C 2.1, 

With one window open in show windows view, dismissing it will leave browser in a blank white screen.

Flame 2.1

Environmental Variables:
Device: Flame 2.1 (512 mb)
Build ID: 20140915000203
Gaia: 944e5b4582c4efa1b67cd33245dbb8f6aa25d09f
Gecko: 7546fedad918
Version: 34.0a2 (2.1)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.

Open C 2.1

Environmental Variables:
Device: Open_C 2.1
BuildID: 20140915000203
Gaia: 944e5b4582c4efa1b67cd33245dbb8f6aa25d09f
Gecko: 7546fedad918
Version: 34.0a2 (2.1)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


This issue does NOT ooccur on Flame 2.2(319mb), and Open C 2.2

Browser is closed as intended 

Flame 2.2 (319mb)

Environmental Variables:
Device: Flame Master
Build ID: 20140915040203
Gaia: 855be6ade407c26e0596e7306a44deebc3f60933
Gecko: f27ff178807d
Version: 35.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Open C 2.2

Environmental Variables:
Device: Open_C 2.2
BuildID: 20140915040203
Gaia: 855be6ade407c26e0596e7306a44deebc3f60933
Gecko: f27ff178807d
Version: 35.0a1 (2.2)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Issue does not occur on flame 2.0(319mb) or open C 2.0

feature was not yet implemented 

Flame 2.0

Environmental Variables:
Device: Flame 2.0
Build ID: 20140915000202
Gaia: 7edd3b0b9f65c3dde235c732d270e43e055a1254
Gecko: 13e04ab68621
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open_C 2.0

Enviromental Variables:
Device: Open_C 2.0
BuildID: 20140915000202
Gaia: 7edd3b0b9f65c3dde235c732d270e43e055a1254
Gecko: 13e04ab68621
Version: 32.0 (2.0)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Marcia Knous [:marcia]]

I wasn't able to repro this using yesterday's build - we may need a better set of STR.

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

Adding qawanted to get a better STR.

Comment 4

[Cody Roesch [:croesch]]

I was able to successfully get this issue on the Flame 2.1 KK build below. Just following the steps in comment 0, the bug occurred each time I attempted it. 5/5

Environmental Variables:
Device: Flame 2.1
BuildID: 20140916065549
Gaia: 5753b75bdd644f0e58536becd702779364340a4b
Gecko: 333807127cd1
Version: 34.0a2
Firmware Version: v165
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 5

[Joshua Mitchell (Inactive)]

On one hand this bug does not affect functionality and has an easy recovery state (just press home button) but on the other hand this is a glaring all-white screen that is obviously a bug and bad UX.

NI on the Browser QA owner / Marcia to weigh in on a blocker nomination call please.

Comment 6

[Marcia Knous [:marcia]]

Can we please retest this with the latest build?

Comment 7

[Cody Roesch [:croesch]]

I am still able to reproduce this bug on Flame 2.1 KK by following the STR using the browser. The first couple attempts typing words into rocketbar did not produce the issue. I opened browser then tapped on the search bar and typed in a word and did the STR and the bug reproduces.

3/3 from browser
0/5 from rocketbar

Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20140922053548
Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91
Gecko: 185fc54d29c1
Version: 34.0a2
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 8

[KTucker [:KTucker][Inactive 3/4/2016]]

This issue is no longer reproducing on the latest 2.2(319mb)(kk) build and not occurring through the Rocket bar on 2.1(319mb)(KK) based on comment 7 so closing this issue as worksforme since the browser app will be removed from 2.1.

Comment 9

[Parul Mathur]

Able to reproduce on b2g 2.1 with clarity on when it occurs and when it doesn't.

Test Environment:
Device: Firefox OS reference phone
OS Version: b2g 2.1.0.0-prerelease
BuildID: 20141001000202
Platform Version: 34.0a2
Gaia: 86a36260
Update channel: aurora
Git commit info: 2014-09-30 23:51:39


Steps to reproduce:
1. Open any app on the phone (e.g. the music app or the contacts app).
2. Long press the Home screen button to bring up the Rocketbar.
3. Start typing a search term in the Rocketbar like "tech".
4. Search results appear. Tap on the green TechCrunch icon in the first row of app suggestions.
5. While the mobile website is rendering, tap on the ellipsis button next to the URL.
6. From the context menu, select "Show windows".
7. On the TechCrunch window, tap on the black cross in the upper left corner to close the window.


Actual Results:
A white screen remains that occurs no navigation guidance to the user. (See adb logcat attached.)

Expected Results:
The home screen appears.

Note:
This bug is NOT reproducible under the following circumstances:
1. When no other app is opened (i.e. Skip Step 1 above and just do Steps 2 through 7.)
2. When 2 mobile websites are launched and then closed (i.e. Skip Step 1 above and repeat Steps 3 and 4 for a different search term and then go on to Step 5.)

Comment 10

[Marcia Knous [:marcia]]

[Blocking Requested - why for this release]: Nominating for blocking. When this occurs it is not a good user experience to be left in a white screen, even though the user can recover from this state.

Thanks Parul for finding a good set of STR for this bug.

Comment 11

[Gregor Wagner [:gwagner]]

Aus, is this expected?

Comment 12

[Kevin Grandon :kgrandon]

Based on the STR in comment 9 it seems like task manager may be missing some event if we access it too quickly? Just a guess.

Comment 13

[Aus Lacroix [:aus]]

Hmmm, no, we should normally dismiss the task manager when there are no cards left (including when we've filtered). This does sound like a legit issue to me. I can probably take a look at this tomorrow. I think it should be an easy fix.

Comment 14

[Francis Djabri [:djabber]]

Just to confirm from UX - the expected behavior in comment 9 (returning to the homescreen) sounds good to me.

Comment 15

[Gregor Wagner [:gwagner]]

Really bad UX

Comment 16

[Sam Foster [:sfoster] (he/him)]

Stealing this. Aus, you can have it back tomorrow if you want, but I think I see what's going on here.

Comment 17

[Sam Foster [:sfoster] (he/him)]

Attachment: v2.1 exit to app or homescreen

Since bug 1071852, this logic can be simplified greatly. The patch avoids the trap where StackManager's getCurrent falls back to AppWindowManager's activeApp - which is not yet updated and points to the app we just killed. This was the cause of the symptoms described - we were trying to open a dead app. 

Also fixed unit 'when exitToApp is passed no app' test which now clarifies and agrees with the expected 'home' button behavior in v2.1

Comment 18

[Sam Foster [:sfoster] (he/him)]

For the record, this was regressed in v2.1 by bug 1065511.

Comment 19

[Sam Foster [:sfoster] (he/him)]

(In reply to Sam Foster [:sfoster] from comment #18)
> For the record, this was regressed in v2.1 by bug 1065511.

Oh that cant be right, the reports pre-date that landing. It must date back to bug 1047143

Comment 20

[Etienne Segonzac (:etienne)]

Comment on attachment 8500708 [details] [review]
v2.1 exit to app or homescreen

all good

Comment 21

[Sam Foster [:sfoster] (he/him)]

Comment on attachment 8500708 [details] [review]
v2.1 exit to app or homescreen

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Task Manager, incomplete fix in bug 1071852
[User impact] if declined: User can easily end up in a state where they apparently cannot leave the task manager and get to homescreen 
[Testing completed]: Unit tests fixed, manual testing on Flame with 2.1/aurora
[Risk to taking this patch] (and alternatives if risky): Should be low risk, this patch tidies up loose-ends left from 1071852
[String changes made]: None

Comment 22

[Gregor Wagner [:gwagner]]

NI fabrice since its a 2.1 only bug.

Comment 23

[Sam Foster [:sfoster] (he/him)]

We're getting a UI test failure with this patch: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=0298bd361be3

I've not yet had any luck tracking down the issue, or grasping why this patch would cause this change in outcome (or, alternately why the test was passing before.) Its presumably some race condition or other test artifact but we should make it green before landing on 2.1. So I'm enlisting help - here's the report and stack trace I get running the test locally: 

TEST-START | test_cards_view_kill_apps_with_two_apps.py TestCardsViewTwoApps.test_kill_app_from_cards_view
TEST-UNEXPECTED-ERROR | test_cards_view_kill_apps_with_two_apps.py TestCardsViewTwoApps.test_kill_app_from_cards_view | StaleElementException: StaleElementException: The element reference is stale. Either the element is no longer attached to the DOM or the page has been refreshed.


Traceback (most recent call last):
  File "/home/sfoster/.virtualenvs/gaia-ui-tests/local/lib/python2.7/site-packages/marionette_client-0.8.3-py2.7.egg/marionette/marionette_test.py", line 171, in run
    testMethod()
  File "/home/sfoster/gaia/tests/python/gaia-ui-tests/gaiatest/tests/functional/cards_view/test_cards_view_kill_apps_with_two_apps.py", line 37, in test_kill_app_from_cards_view
    self.cards_view.close_app(self._test_apps[0])
  File "/home/sfoster/gaia/tests/python/gaia-ui-tests/gaiatest/apps/system/regions/cards_view.py", line 49, in close_app
    self.wait_for_card_ready(app)
  File "/home/sfoster/gaia/tests/python/gaia-ui-tests/gaiatest/apps/system/regions/cards_view.py", line 34, in wait_for_card_ready
    self.wait_for_condition(lambda m: current_frame.size['width'] - card.size['width'] == 2 * card.location['x'])
  File "/home/sfoster/gaia/tests/python/gaia-ui-tests/gaiatest/apps/base.py", line 56, in wait_for_condition
    Wait(self.marionette, timeout).until(method, message=message)
  File "/home/sfoster/.virtualenvs/gaia-ui-tests/local/lib/python2.7/site-packages/marionette_client-0.8.3-py2.7.egg/marionette/wait.py", line 122, in until
    rv = condition(self.marionette)
  File "/home/sfoster/gaia/tests/python/gaia-ui-tests/gaiatest/apps/system/regions/cards_view.py", line 34, in <lambda>
    self.wait_for_condition(lambda m: current_frame.size['width'] - card.size['width'] == 2 * card.location['x'])
  File "/home/sfoster/.virtualenvs/gaia-ui-tests/local/lib/python2.7/site-packages/marionette_client-0.8.3-py2.7.egg/marionette/marionette.py", line 151, in size
    return self.marionette._send_message('getElementSize', 'value', id=self.id)
  File "/home/sfoster/.virtualenvs/gaia-ui-tests/local/lib/python2.7/site-packages/marionette_client-0.8.3-py2.7.egg/marionette/decorators.py", line 35, in _
    return func(*args, **kwargs)
  File "/home/sfoster/.virtualenvs/gaia-ui-tests/local/lib/python2.7/site-packages/marionette_client-0.8.3-py2.7.egg/marionette/marionette.py", line 638, in _send_message
    self._handle_error(response)
  File "/home/sfoster/.virtualenvs/gaia-ui-tests/local/lib/python2.7/site-packages/marionette_client-0.8.3-py2.7.egg/marionette/marionette.py", line 676, in _handle_error
    raise errors.StaleElementException(message=message, status=status, stacktrace=stacktrace)

TEST-INFO took 15434ms

SUMMARY
-------
passed: 0
failed: 1
todo: 0

FAILED TESTS
-------
test_cards_view_kill_apps_with_two_apps.py test_cards_view_kill_apps_with_two_apps.TestCardsViewTwoApps.test_kill_app_from_cards_view
SUITE-END | took 15s

Comment 24

[Etienne Segonzac (:etienne)]

I don't know how it passed before and we should definitely double check the following with the gaia-ui team but I think the test should be:

* |self.cards_view.close_app(self._test_apps[1])|
* | self.assertFalse(self.cards_view.is_app_present(self._test_apps[1]),
    "Killed app not expected to appear in cards view")|
* |self.cards_view.close_app(self._test_apps[1], <magic parameter telling the method not to wait>)|
* |self.cards_view.wait_for_cards_view_not_displayed()|

Because as soon as we kill the second app we (rather violently) rip out the entire card view DOM while exiting to the homescreen.

Comment 25

[Aus Lacroix [:aus]]

Wow, I'm amazed that passed when we did the huge refactoring. I think it's normally OK to disable a faulty python test and ask the a-team to update it, which they usually do fairly quickly. JGriffin is a good person to talk to as well to double check if Etienne's suggested updated test is what they would like. :)

Comment 26

[Sam Foster [:sfoster] (he/him)]

I've reworked the wait_for_card_ready method to check the close button is displayed (its hidden until the card is finished transitioning and current/centered). That seems to have got around the staleelement issue, and I added a few more assertions in there for good measure. 

As the layout of the task manager and sequence of events around app closing is quite different in master/2.2, I think we just need to be satistfied that the test as it stands is not lying. AFAICT that is now true, we'll see what the gaia-try results look like: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=c4dba05f2a00

Comment 27

[Sam Foster [:sfoster] (he/him)]

Comment on attachment 8500708 [details] [review]
v2.1 exit to app or homescreen

gaia-try results pending, Zac do the changes to cards_view.py and test_cards_view_kill_app_with_two_apps.py seem reasonable?

Comment 28

[Zac C (:zac)]

Sam, yes that looks good and calms down what was obviously a bit of a race condition before.. f+! (and Gaia-Try is green!)

Comment 29

[Zac C (:zac)]

Comment on attachment 8500708 [details] [review]
v2.1 exit to app or homescreen

(forgot to set it ;))

Comment 30

[Sam Foster [:sfoster] (he/him)]

Merged to v2.1: https://github.com/mozilla-b2g/gaia/commit/6cc93702284648c4f697cf89e3cecea6f26187dc

Comment 31

[[:RJ]]

This has been verified fixed in Flame 2.1 KK (319mb) (Full Flash) 

when single window open in browser go to show windows and dismissing the window no longer leaves a white screen and simply closes out the app to the home screen.  

2.1 KK (319mb) (Full Flash)

Environmental Variables:
Device: Flame 2.1 KK (319mb) (Full Flash)
Build ID: 20141010000201
Gaia: d71f8804d7229f4b354259d5d8543c25b4796064
Gecko: 7fa82c9acdf2
Version: 34.0a2 Flame 2.1 KK (319mb)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0