1255880 - Persist tabs at more carefully chosen moments

Status: NEW

(Firefox for iOS :: General, defect)

Description

[Richard Newman [:rnewman]]

Follow-on from Bug 1249828.

My tentative proposal from that bug:

---
Assuming that we don't use this particular pile of persisted tab state for anything but Sync, we really just want to persist at two times:

* Immediately before a sync while the app is in the foreground.
* Immediately before we're backgrounded (because if we do it any later, the webviews are gone!).

There's a second decision, which is when/whether to trigger a sync as a result of browsing activity -- browse enough and we should probably sync your tabs… and in the course of so doing we will persist them.

Does that sound sane to you, Emily?
---

Comment 1

[Emily Toop (:fluffyemily)]

That sounds sane.

We should bear in mind that we persist to disk constantly, so when we persist to storage for sync, we don't even really need to read the current tab state as it is - we only need to read the persisted state on disk. That means we could do that after the webviews have been discarded if we felt that would be better.

What would constitute a significant amount of state change to trigger a sync? I guess creation and deletion of tabs themselves to any great number should count, but probably many site changes within a single tab would be less of a driver?

Comment 2

[Richard Newman [:rnewman]]

(In reply to Emily Toop (:fluffyemily) from comment #1)

> What would constitute a significant amount of state change to trigger a
> sync? I guess creation and deletion of tabs themselves to any great number
> should count, but probably many site changes within a single tab would be
> less of a driver?

See Bug 1222594 for some long-winded thoughts from me on this topic :)