All open private tabs occasionally crash
Categories
(Firefox for Android :: General, defect, P3)
Tracking
()
People
(Reporter: Webworkr, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: crash)
Attachments
(5 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Android 13; Mobile; rv:109.0) Gecko/115.0 Firefox/115.0
Steps to reproduce:
- Open one or more new tabs in private mode.
- Switch to standard mode or open another app (multitasking).
- Return to the private mode.
Actual results:
Sometimes private tabs are closed when you return.
Expected results:
Private tabs remain open.
Reporter | ||
Comment 1•2 years ago
|
||
This bug is based on https://github.com/mozilla-mobile/fenix/issues/19852 and also occurs under changed hardware and Android version.
Private tabs only kept in memory (not persisted on disk), if you run ram
demanding apps while firefox is in the background, the OS may kill
firefox from ram losing your private session.
In comparison, Google Chrome crashes much less often. Private tabs usually stay open as well, as long as the browser app is.
Have you disabled the private browsing notification? Generally the
notification should keep the private tabs alive. If you do not get the
notification check your Android Settings for notifications. Some
aggressive task killers or battery saver modes can hard kill the Firefox
process. The other case where this can happen is if Play updates
Firefox. This will cause a full restart of the app. There is not
anything that can be done for the cases outlined. If you can get
reproducible steps that don't cover the above known behavior please open
a new issue with the details and we can evaluate it.
I'm not aware of specifically disabling notifications for private Firefox browsing.
Comment 2•2 years ago
|
||
The severity field is not set for this bug.
:jonalmeida, could you have a look please?
For more information, please visit BugBot documentation.
Reporter | ||
Comment 3•2 years ago
|
||
The phenomenon still occurs occasionally:
Nightly
119.0a1 (Build #2015974145), afe25e2fd9+
GV: 119.0a1-20230914093829
AS: 119.20230914050403
Comment 4•2 years ago
|
||
Hi Denis,
I would like to clarify one point here. What do you mean by closed? Can you not see the tabs in the tabs bottom sheet, or it is just the tabs reloading when you go back to the app? According to your answer, I will either put this under Tabs Reloading meta ticket or consider this as a separate one for missing the tabs from tabs tray. Thank you.
Reporter | ||
Comment 5•2 years ago
|
||
Hello Kayacan,
the tabs are actually closed. The individual tabs are no longer visible.
Greetings Denis
Reporter | ||
Comment 6•2 years ago
|
||
Recreated screenshot
Reporter | ||
Comment 7•1 years ago
|
||
The phenomenon still occurs occasionally:
Nightly
124.0a1 (Build #2016000071), c8248adb27+
GV: 124.0a1-20240127092204
AS: 124.20240127050245
Updated•1 year ago
|
Reporter | ||
Comment 9•1 year ago
|
||
The phenomenon still occurs occasionally:
Nightly
125.0a1 (Build #2016007271), 7ae5f4f95a+
GV: 125.0a1-20240304212558
AS: 125.20240302000149
Reporter | ||
Comment 10•1 year ago
|
||
The phenomenon still occurs occasionally:
Nightly
126.0a1 (Build #2016013391), hg-68ef8d3216be+
GV: 126.0a1-20240405214302
AS: 126.20240403050706
Reporter | ||
Comment 11•1 year ago
|
||
The phenomenon still occurs occasionally:
Nightly
127.0a1 (Build #2016015303), hg-61472b53afe5+
GV: 127.0a1-20240415203932
AS: 126.20240410050314
Reporter | ||
Comment 12•1 year ago
|
||
The phenomenon still occurs occasionally:
128.0a1 (Build #2016020879), hg-b2c1906d3f6e+
GV: 128.0a1-20240514215634
AS: 128.20240514050332
Reporter | ||
Comment 13•1 year ago
|
||
Maybe related to bug 1862661?
Reporter | ||
Comment 14•1 year ago
|
||
Maybe related to bug 1898868?
Reporter | ||
Comment 15•1 year ago
|
||
The phenomenon still occurs occasionally:
129.0a1 (Build #2016026447), hg-157e7e735044+
GV: 129.0a1-20240612215151
AS: 129.20240612050250
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Comment 16•1 year ago
|
||
Originally posted by @kbrosnan in https://github.com/mozilla-mobile/fenix/issues/19852#issuecomment-856181532
[...] Some aggressive task killers or battery saver modes can hard kill the Firefox process. [...]
Yesterday I changed the default setting for the battery to "Unrestricted". This did not bring any improvement.
Reporter | ||
Comment 17•1 year ago
|
||
Reporter | ||
Comment 18•1 year ago
|
||
Originally posted by @kbrosnan in https://github.com/mozilla-mobile/fenix/issues/19852#issuecomment-856181532
Have you disabled the private browsing notification? Generally the notification should keep the private tabs alive. If you do not get the notification check your Android Settings for notifications. Some aggressive task killers or battery saver modes can hard kill the Firefox process. […]
The notifications are active by default and I don't delete these push notifications.
Reporter | ||
Comment 19•1 year ago
|
||
PUSH notification to maintain private mode
Reporter | ||
Comment 20•1 year ago
|
||
The phenomenon still occurs occasionally:
130.0a1 (Build #2016031439), hg-162448b8b7cd+
GV: 130.0a1-20240708220117
AS: 129.20240704050322
Reporter | ||
Comment 21•1 year ago
|
||
Originally posted by @kbrosnan in https://github.com/mozilla-mobile/fenix/issues/19852#issuecomment-856181532
The other case where this can happen is if Play updates Firefox. This will cause a full restart of the app.
The browser update process is explicitly not the subject of my error report.
Reporter | ||
Comment 22•11 months ago
|
||
The phenomenon still occurs occasionally:
131.0a1 (Build #2016037311), hg-22f4cf67e8ad+
GV: 131.0a1-20240808093537
AS: 131.20240806050256
Reporter | ||
Comment 23•11 months ago
|
||
"Settings" menu > "About Firefox Nightly" > "Crashes":
The crash of the private tabs is not logged.
Reporter | ||
Comment 24•10 months ago
|
||
The phenomenon still occurs occasionally:
132.0a1 (Build #2016042863), hg-9df162c80958+
GV: 132.0a1-20240906093607
AS: 132.20240904050246
Reporter | ||
Comment 25•10 months ago
|
||
Severity and priority have already been assigned. However, this bug is still unconfirmed. What's the problem?
Comment 26•10 months ago
|
||
I've locally confirmed this case when the main process of the app is getting killed in the background and in that case we recreate the app process once we go back to the application. Due to the private app session recreation and not persisting the users' state, the new app session will have no private tabs saved. So it looks like it is not actually a crash but rather the death of main app process. Worth mentioning, this issue would not happen if main process continued living but child (tab) processes died, in which case, a tab reload would happen and the private tabs would still be kept.
This issue will be addressed by the improvements being worked on under Tab Reloading issue where our aim is to keep our app processes alive longer.
Worth mentioning that, this issue is also dependent on other external factors such as the amount of resource pressure being put on by the other applications while the Fenix is in the background. (e.g. if too much memory is being consumed by another foregrounded app, eventually it may result OS killing backgrounded apps in order to provide enough resources to the system and the app in the foreground. Therefore, the improvements being currently worked on is aiming to increase the lifespan of the processes but cannot guarantee that this issue will never happen again.)
ni'ing Roger to take a look at the linked ticket (regarding crash reporting of the private tabs, and whether it is sth we would want to have). That ticket would help us make sure if there's a user-perceived crash on child processes or it is indeed what I just described, ie. main process death signaled by the OS due to excessive resource usage and/or system under memory pressure. Anyways, I'll still be linking this to Tab Reloading ticket, until we prove otherwise.
Updated•10 months ago
|
Reporter | ||
Comment 27•10 months ago
|
||
The phenomenon still occurs occasionally:
133.0a1 (Build #2016047847), hg-5e05e4e4f2ac+
GV: 133.0a1-20241002095009
AS: 133.20241001050328
Comment 28•9 months ago
|
||
I can confirm that this issue is not related to private tab crashes but rather to Fenix being terminated by Android OS in the background. Currently, we do not persist private tabs to ensure user privacy, so whether Fenix is closed manually by the user or by Android OS (a distinction we can't reliably detect), we don’t face the risk of unintentionally restoring private tabs.
Moving forward, I believe the focus should be on preventing Fenix from being killed by the OS (through upcoming performance and memory optimizations), rather than persisting private tabs, which could introduce privacy risks.
Reporter | ||
Comment 29•9 months ago
|
||
The phenomenon still occurs occasionally:
134.0a1 (Build #2016052927), hg-20aa234dca65+
GV: 134.0a1-20241028212656
AS: 133.20241027050311
Description
•