Currently, as per bug 582244 private and non-private data are saved in a different way. Private data is sent to Android to be kept secure in ActivityManager's memory, non-private data is persisted on disk. As a follow-up to bug 1513938 we should try to find a better way to store the Private Browsing session as the current solution is not feasible - the session could contain more data than the Bundle can work with (currently 1 MB for all Binder transactions in progress for the process [1]) [1] https://developer.android.com/reference/android/os/TransactionTooLargeException

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #7) > (In reply to Jan Henning [:JanH] from comment #6) > > If the comments in SessionHistory.jsm [1]/nsISHEntry.idl [2] are still > > accurate, the structuredCloneState seems to be the serialisation of data > > that sites have stored using the pushState API > > (https://developer.mozilla.org/en-US/docs/Web/API/ > > History_API#Adding_and_modifying_history_entries). > > > > (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #5) > > > I think my suggestion to avoid this problem may be to store it outside of the Bundle, > > > and only store some key for accessing the data in the bundle. > > > > To clarify, you mean encrypting the private browsing data with a random key, > > writing the data itself to storage, but storing the encryption key as part > > of the savedInstance state? > > > > No I mean continue keeping it in memory somewhere, just not in the Bundle. A > HashMap somewhere, with the key stored in the Bundle. Could you expand a little on how your proposal is supposed to work regarding OOM kills?

(In reply to Jan Henning [:JanH] from comment #1) > (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #7) > > (In reply to Jan Henning [:JanH] from comment #6) > > > If the comments in SessionHistory.jsm [1]/nsISHEntry.idl [2] are still > > > accurate, the structuredCloneState seems to be the serialisation of data > > > that sites have stored using the pushState API > > > (https://developer.mozilla.org/en-US/docs/Web/API/ > > > History_API#Adding_and_modifying_history_entries). > > > > > > (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #5) > > > > I think my suggestion to avoid this problem may be to store it outside of the Bundle, > > > > and only store some key for accessing the data in the bundle. > > > > > > To clarify, you mean encrypting the private browsing data with a random key, > > > writing the data itself to storage, but storing the encryption key as part > > > of the savedInstance state? > > > > > > > No I mean continue keeping it in memory somewhere, just not in the Bundle. A > > HashMap somewhere, with the key stored in the Bundle. > > Could you expand a little on how your proposal is supposed to work regarding > OOM kills? Right, I guess we wouldn't be able to restore it in that case. We'd need to persist it on disk somewhere. Pretty edge-casey IMHO.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.