Session Lost after Timeout: restore session state

[athomasmoz]

Steps to reproduce

1. Open the browser to a website
2. Wait 5mins - it will time out and take you back to the device homescreen
3. Say "Alexa, reopen Firefox"

Expected behavior

Option 1: Firefox opens to the website you were viewing Option 2: Firefox opens to the homescreen overlay with an easy way to get back to the site you were viewing

Actual behavior

Firefox opens to the homescreen with the URL bar blank and no apparent way to return to the site you were on

Device information

• Echo Show device (1st gen? 2nd?): 2nd
• Firefox version: 1.2

Considerations

This came from a review, here's the exact use case: " I opened up the browser to a recipe site and started cooking dinner. After a couple minutes, the device times out and returns to the home screen! "Alexa, reopen my browser" should get me back to the page I was on right? No! It takes me back to the home page and I have to navigate to the recipe again. Rinse and repeat every two minutes until I give up and open up a physical cookbook."

[mcomella]

We do actually have session restoration code, e.g. https://github.com/mozilla-mobile/firefox-echo-show/blob/8952c0e11cc1073bcf7da628e8bdc515cc3d453b/app/src/main/java/org/mozilla/focus/iwebview/IWebViewLifecycleFragment.kt#L51-L56

And trying with "Don't Keep Activities" enabled, it looks like it's restoring the currently displayed web page correctly but not restoring the toolbar state (in fact, the toolbar url, back/forward, etc. state never updates after we restore state).

However, it's strange that user's experiences are different than ^: I wonder if the Show is killing us more aggressively than stock Android.

Action items for this bug:

• Test (for myself) what happens after the device times out. Consider adding logs to see if the saveState methods are called
• If the restoration behavior is different, contact Amazon
• Implement correct state restoration behavior
• Implement tests for correct state restoration behavior. Note that #117 is refactoring some code and may change the restoration behavior (i.e. that the navigation overlay fragment will be restored whereas the overlay was not in a fragment so couldn't be restored before)

[mcomella]

And trying with "Don't Keep Activities" enabled, it looks like it's restoring the currently displayed web page correctly but not restoring the toolbar state (in fact, the toolbar url, back/forward, etc. state never updates after we restore state).

I opened a PR to fix this issue. However, I'll still need to investigate on device to see if the state restoration works differently there.

[mcomella]

Note: Firefox session state is not lost when opening skills e.g. "Echo, what's the weather?"

Firefox session state is lost when opening Silk (another app, as opposed to skill) but that could be because it's too resource intensive to have both Silk and Firefox open.

---

I confirmed on device that the process is killed when firefox is backgrounded. In order to restore state after backgrounding, we either need to:

1. Request to Amazon that we can stay in memory for some duration (like stock Android)
2. Save the data to disk and restore it on start.
   • This would force users to reload the page every time they reopen Firefox and readjust their scroll position (we may be able to save that too...)
   • Silk does this but only restores the last page you were on, not the whole back stack
   • Restoring the back stack may not be possible because WebView is expecting to store/restore the state and it may only be able to handle data from memory

I'd prefer option 1 because it keeps us standard with our behavior on stock Android and doesn't force users to reload the page.

An alternative is that we can provide users the option to keep the screen on #146 and then we don't need to handle this case.

@athomasmoz Do you think it's appropriate to request Amazon to change their timeout behavior so that our app can stay open in the background for some duration so users can restore their session?

[athomasmoz]

Thanks for checking this out.

This ticket was added to our sprint as a way to lessen the pain for users who keep getting timed out in the middle of a task (ie. going through a recipe), while we wait for Amazon to hopefully increase the timeout. So at least if they get timed out, they can reopen the browser and return to their task.

I think option 1 is a good idea in general, but I'm worried about blocking this issue on it. I think the best thing we can do is make a strong case to Amazon about the problem and then work with them on timing for a solution. If they aren't able to address one of the issues soon (timeout or restoring session), then we can look at option 2.

As a first step, let's grab data to support our case. Do you know if we can get numbers on:

• How often the timeout occurs
• How often the app is reopened within 5mins of closing it

[mcomella]

How often the timeout occurs

We can't tell if the app was closed by the system or if the user intentionally closed it.

How often the app is reopened within 5mins of closing it

Instead, I believe we can answer our question by comparing the number of session closes to reopens within five minutes: for a given telemetry ID, for a given telemetry ID, we can check each session end probe and see if the next session start probe occurs within five minutes: I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1517832 for the data analysis.

A few problems with this data though:

• This is a bad experience so users may have stopped using the device for anything that needs a long timeout (e.g. recipes) so they won't show up in the data
• (thought I had something else...)

[mcomella]

N.B.: we don't receive the onStop callback when the screen times out – #172. This might be why session restoration is not working in the first place.

[mcomella]

Result of the initial discussion with athomas and Felix: we understand users whose last interactions with our current UI probes (i.e. browser chrome) was five minutes before the session ends but do not understand users who interacted with the browser five minutes before the session ends. We want to add a probe to understand these users. Due to implementation complexities, we will ignore users who are watching videos that are not interacting via touch but whose timeout is delayed (to 8 hours, provided a video keeps playing) by watching videos.

Action items:

• Add telemetry probe that triggers 4.5 minutes after last touch event
  • The analysis will see if the session ends ~30s after that probe, then we can understand the behavior of users who interacted with page content before the timeout
• If data shows this is a common use case, attempt to restore sessions
• If data shows this is a common use case, ask Amazon about better session restoration mechanisms and increased timeouts

[mcomella]

Spoke with Felix and athomas: we discovered we could use "session end in one process and start in another" as a heuristic for timeouts and we quantitatively, the fraction of timeouts where users open a session soon after is not large. However, what we really want to identify is what fraction of users are affected by this, rather than the fraction of timeouts. The best way to do this is anecdotally (e.g. surveys) or standins. Waiting on @athomasmoz to decide which path we want to take.

[athomasmoz]

Closing issue off. Felix has done investigation and not found evidence to prove our hypothesis that this is an issue affecting a significant number of users.

We have decided to run tests to determine if restoring session is a preferred experience to starting the browser fresh each time.