1990978 - Deleted history pages reappear upon Firefox restart

Status: VERIFIED FIXED

(Firefox for Android :: History, defect, P1)

Description

[Bojan Nešić]

User Agent: Mozilla/5.0 (Android 15; Mobile; rv:143.0) Gecko/143.0 Firefox/143.0

Steps to reproduce:

1. Opened Firefox 143.0.2 for Android on an Android 15 device.
2. In the History view, long-pressed and deleted specific pages.
3. Fully closed and restarted the app.
4. Noticed that the same deleted entries reappeared in history.
5. Went to ⋮ → Settings → Delete browsing data on quit, toggled it On, and then unchecked every data type.
6. Returned to the three-dot menu and saw that the Quit entry had vanished.
   (I'm not logged in into Firefox Sync, by the way. Also, I'm using Firefox in Serbian, so exact terms for specific functions and buttons in English version of Firefox may be different than my translation.)

Actual results:

Deleted history entries are never committed to the database—on restart they reappear — and because Quit only shows when at least one data type is selected under “Delete browsing data on quit” there’s no way to perform a clean exit (which would flush manual deletions) without wiping all or some data.

Expected results:

When “Delete browsing data on quit” is enabled, Quit should remain visible even if no data types are checked, allowing users to trigger a proper shutdown (checkpointing the SQLite WAL) so that selective deletions persist without forcing a full data purge.

Comment 1

[dan.sibo7522]

Having same problem with 143.02 (Build #2016116031) Firefox on Galaxy S22.

Comment 2

[Cathy Lu [:calu]]

Is this SHIP related or should squad 4 take a look at this history related issue?

Comment 3

[Bojan Nešić]

I've cleared cache, uninstalled the app, removed residue files using Google Files and File Manager, restarted the phone, and installed the latest stable version of Firefox from Google Play Store, but the problem remains. I didn't log in to Firefox Sync.

Comment 4

[Jonathan Almeida [:jonalmeida]]

There is good overlap with bug 1991249, so once that is fixed we should have this re-tested.

Comment 5

[:Gela]

Attachment: Bug 1990978 - Bring back the snackbar with Undo button for when a history item is deleted

Comment 7

[:Gela]

I have a patch up to revert the removal of that specific snackbar here: https://phabricator.services.mozilla.com/D266738

During my testings I've noticed a similar (but different) bug that is not caused as a part of my patch but we should look into eventually.
The logic of committing item deletions to a "pending" state and deleting them once the snackbar disappears is concerning because visually, we are essentially tricking users into thinking that their browsing history is deleted when it is not. This means if user swipes away to quit the app before the snackbar disappears, all of their deleted history items will come back upon the next launch.

Comment 8

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Without this patch if user deletes one or multiple items from their search history, we visually remove those from the list, but as soon as they restart the app, those items will reappear. This can leak personal browsing info and have disastrous impacts on users' privacy.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Listed in the ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1990978
• Risk associated with taking this patch: low
• Explanation of risk level: We are reverting a patch
• String changes made/needed: 2 strings that were previously marked as unused are reintroduced back.
• Is Android affected?: yes

Comment 9

[:Gela]

Attachment: Bug 1990978 - Bring back the snackbar with Undo button for when a history item is deleted r=android-reviewers,jonalmeida

This patch essentially reverts this change from back in 143: https://phabricator.services.mozilla.com/D255847

The original patch removed the snackbar that was shown when user deleted one or multiple history items from the list. The complexity here lies in the fact that even though we visually remove the item from the list, under the hood we do not actually remove the item(s) until the snackbar is shown and has gone away. Instead, we add the item(s) to a pending list to be deleted "eventually".

Since the original patch simply removed the snackbar visually but did not actually change the logic under the hood to perform the deletion immediately, once user restarts the app, all of their presumably deleted history would reappear.

Given the severity of this issue I am going to reintroduce the snackbar to resolve this since it's the fastest and safest solution. We can then look into updating the entire logic stack to honor deletions immediately.

Original Revision: https://phabricator.services.mozilla.com/D266738

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4ece4463251e
https://hg.mozilla.org/integration/autoland/rev/a7f672005bb2
Bring back the snackbar with Undo button for when a history item is deleted r=android-reviewers,jonalmeida

Comment 11

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/a7f672005bb2

Comment 12

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/028cd7b6d405
https://hg.mozilla.org/releases/mozilla-beta/rev/0a99cd55d966

Comment 13

[Lorand Janos]

Attachment: Edited_20251001_134327.mp4

Hi,

I've tested this in the latest Nightly build (2025-10-01) with the following results:

• The snackbar is displayed after one or more history item(s) is/are deleted;
• The Undo button works as expected, the deleted items are redisplayed on Undo;
• After waiting for the ~5 seconds for the snackbar no longer be displayed, then closing and opening the app, the deleted item(s) remain(s) deleted;
• Closing and reopening the app while the snackbar is still displayed results in the deleted item to be displayed again.

Tested devices: Samsung Galaxy S23 Ultra and OnePlus 12R (Android 15).

Since the snackbar was the focus in this ticket, and it's correctly displayed and works correctly, I will mark the ticket as verified on 145. Leaving the original issue (redisplayed history item on closing-reopening in a given time) to be addressed in a different ticket.

Comment 14

[Lorand Janos]

Attachment: Recording_20251001_134521.mp4

Comment 15

[Lorand Janos]

Tested on the latest Beta build as well (144.0b8).

The results were identical to the ones in Nightly, described above.

Tested devices: Samsung Galaxy S23 Ultra and OnePlus 12R (Android 15).

Marking the ticket as Verified on 144 as well.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Please add a release uplift request on this. I'm thinking about spinning an Android 143.0.4 release tomorrow to address this and another frequent crash.

Comment 17

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: Without this patch if user deletes one or multiple items from their search history, we visually remove those from the list, but as soon as they restart the app, those items will reappear. This can leak personal browsing info and have disastrous impacts on users' privacy.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Listed in the ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1990978
• Risk associated with taking this patch: low
• Explanation of risk level: We are reverting a patch
• String changes made/needed: 2 strings that were previously marked as unused are reintroduced back.
• Is Android affected?: yes

Comment 18

[:Gela]

Attachment: Bug 1990978 - Bring back the snackbar with Undo button for when a history item is deleted

This patch essentially reverts this change from back in 143: https://phabricator.services.mozilla.com/D255847

The original patch removed the snackbar that was shown when user deleted one or multiple history items from the list. The complexity here lies in the fact that even though we visually remove the item from the list, under the hood we do not actually remove the item(s) until the snackbar is shown and has gone away. Instead, we add the item(s) to a pending list to be deleted "eventually".

Since the original patch simply removed the snackbar visually but did not actually change the logic under the hood to perform the deletion immediately, once user restarts the app, all of their presumably deleted history would reappear.

Given the severity of this issue I am going to reintroduce the snackbar to resolve this since it's the fastest and safest solution. We can then look into updating the entire logic stack to honor deletions immediately.

Original Revision: https://phabricator.services.mozilla.com/D266738

Comment 19

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/b98c962b443b
https://hg.mozilla.org/releases/mozilla-release/rev/ac51a1a3c083

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Added to the 143.0.4 relnotes.

Comment 21

[Lorand Janos]

Tested on the latest RC build as well (143.0.4).

The results were identical to the ones in Nightly and Beta described above.

Tested devices: Samsung Galaxy S23 Ultra and OnePlus 12R (Android 15).

Marking the ticket as Verified on 143 as well.